draft-ietf-ccamp-rsvp-te-eth-oam-ext-10.txt   draft-ietf-ccamp-rsvp-te-eth-oam-ext-11.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: December 17, 2013 H. Long Expires: September 2, 2014 H. Long
Huawei Huawei
June 15, 2013 March 2014
GMPLS RSVP-TE Extensions for Ethernet OAM Configuration GMPLS RSVP-TE Extensions for Ethernet OAM Configuration
draft-ietf-ccamp-rsvp-te-eth-oam-ext-10 draft-ietf-ccamp-rsvp-te-eth-oam-ext-11
Abstract Abstract
The GMPLS controlled Ethernet Label Switching (GELS) work extended The GMPLS controlled Ethernet Label Switching (GELS) work extended
GMPLS RSVP-TE to support the establishment of Ethernet LSPs. IEEE GMPLS RSVP-TE to support the establishment of Ethernet LSPs. IEEE
Ethernet Connectivity Fault Management (CFM) specifies an adjunct OAM Ethernet Connectivity Fault Management (CFM) specifies an adjunct OAM
flow to check connectivity in Ethernet networks. CFM can be also flow to check connectivity in Ethernet networks. CFM can be also
used with Ethernet LSPs for fault detection and triggering recovery used with Ethernet LSPs for fault detection and triggering recovery
mechanisms. The ITU-T Y.1731 specification builds on CFM and mechanisms. The ITU-T Y.1731 specification builds on CFM 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 protocol to support the setup of the extensions of GMPLS RSVP-TE protocol to support the setup of the
associated Ethernet OAM entities of Ethernet LSPs, and defines the associated Ethernet OAM entities of Ethernet LSPs, and defines the
Ethernet technology specific TLVs based on [OAM-CONF-FWK]. This Ethernet technology specific TLVs based on the GMPLS OAM
document supports, but does not modify, the IEEE and ITU-T OAM Configuration Framework. This document supports, but does not
mechanisms. modify, the IEEE and ITU-T OAM mechanisms.
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
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
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). 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 September 2, 2014.
This Internet-Draft will expire on December 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Overview of Ethernet OAM operation . . . . . . . . . . . . . . 5 2. Overview of Ethernet OAM operation . . . . . . . . . . . . . 3
3. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . 7 3. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . 5
3.1. Operation overview . . . . . . . . . . . . . . . . . . . . 7 3.1. Operation overview . . . . . . . . . . . . . . . . . . . 5
3.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 9 3.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 7
3.3. Ethernet OAM Configuration Sub-TLV . . . . . . . . . . . . 9 3.3. Ethernet OAM Configuration Sub-TLV . . . . . . . . . . . 7
3.3.1. MD Name Sub-TLV . . . . . . . . . . . . . . . . . . . 10 3.3.1. MD Name Sub-TLV . . . . . . . . . . . . . . . . . . . 8
3.3.2. Short MA Name Sub-TLV . . . . . . . . . . . . . . . . 11 3.3.2. Short MA Name Sub-TLV . . . . . . . . . . . . . . . . 9
3.3.3. MEP ID Sub-TLV . . . . . . . . . . . . . . . . . . . . 12 3.3.3. MEP ID Sub-TLV . . . . . . . . . . . . . . . . . . . 10
3.3.4. Continuity Check (CC) Sub-TLV . . . . . . . . . . . . 12 3.3.4. Continuity Check (CC) Sub-TLV . . . . . . . . . . . . 11
3.4. Pro-active Performance Monitoring . . . . . . . . . . . . 13 3.4. Pro-active Performance Monitoring . . . . . . . . . . . . 11
3.5. Summary of Ethernet OAM configuration errors . . . . . . . 14 3.5. Summary of Ethernet OAM configuration errors . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 4.1. RSVP-TE OAM Configuration Registry . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. Ethernet Sub-TLVs Sub-Registry . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.3. RSVP Error Code . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 19 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Background 1. Background
Provider Backbone Bridging - Traffic Engineering (PBB-TE) Provider Backbone Bridging - Traffic Engineering (PBB-TE)
[IEEE.802.1Q-2011] decouples the Ethernet data and control planes, [IEEE.802.1Q-2011] decouples the Ethernet data and control planes,
and allows external control and management mechanisms to create and allows external control and management mechanisms to create
explicitly routed Ethernet connections. In addition, PBB-TE defines explicitly routed Ethernet connections. In addition, PBB-TE defines
mechanisms for protection switching of bidirectional Ethernet mechanisms for protection switching of bidirectional Ethernet
connections. Ethernet Connectivity Fault Management (CFM) defines an connections. Ethernet Connectivity Fault Management (CFM) defines an
adjunct connectivity monitoring OAM flow to check the liveliness of adjunct connectivity monitoring OAM flow to check the liveliness of
skipping to change at page 6, line 8 skipping to change at page 4, line 21
direction. Therefore, instead of the 3-tuples of the PBB-TE ESPs, direction. Therefore, instead of the 3-tuples of the PBB-TE ESPs,
MEPs must be provisioned with the proper VLAN identifiers. MEPs must be provisioned with the proper VLAN identifiers.
MEPs exchange Connectivity Check Messages (CCMs) periodically with MEPs exchange Connectivity Check Messages (CCMs) periodically with
fixed intervals. Eight distinct intervals are defined in fixed intervals. Eight distinct intervals are defined in
[IEEE.802.1Q-2011]: [IEEE.802.1Q-2011]:
+---+--------------------+----------------+ +---+--------------------+----------------+
| # | CCM Interval (CCI) | 3 bit encoding | | # | CCM Interval (CCI) | 3 bit encoding |
+---+--------------------+----------------+ +---+--------------------+----------------+
| 0 | Reserved | 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 |
| | | | | | | |
| 6 | 1 min | 110 | | 6 | 1 min | 110 |
| | | | | | | |
| 7 | 10 min | 111 | | 7 | 10 min | 111 |
+---+--------------------+----------------+ +---+--------------------+----------------+
Table 1: CCM Interval encoding Table 1: CCM Interval encoding
If 3 consecutive CCM messages are lost; connectivity failure is If 3 consecutive CCM messages are lost; connectivity failure is
declared. The MEP detecting the failure will signal the defect to declared. The MEP detecting the failure will signal the defect to
the remote MEP in the subsequent CCM messages it emits, by setting the remote MEP in the subsequent CCM messages it emits, by setting
the Remote Defect Indicator (RDI) bit in the CCM message. If a MEP the Remote Defect Indicator (RDI) bit in the CCM message. If a MEP
receives a CCM message with RDI bit set it immediately declares receives a CCM message with RDI bit set it immediately declares
failure. The detection of a failure may trigger protection switching failure. The detection of a failure may trigger protection switching
skipping to change at page 8, line 13 skipping to change at page 6, line 13
out of scope of this document. out of scope of this document.
o The desired forwarding priority to be set by MEPs for the CCM o The desired forwarding priority to be set by MEPs for the CCM
frames can be specified. The same CCM priority must be set in frames can be specified. The same CCM priority must be set in
each of the MEPs monitoring a given Ethernet LSP. How CCM each of the MEPs monitoring a given Ethernet LSP. How CCM
priority is determined is out of scope of this document. Note priority is determined is out of scope of this document. Note
that the highest priority should be used as the default CCM that the highest priority should be used as the default CCM
priority. 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-
PBB-TE connections, this requires that the 3-tuples [ESP-MAC A, TE connections, this requires that the 3-tuples [ESP-MAC A, ESP-
ESP-MAC B, ESP-VID1] and [ESP-MAC B, ESP-MAC A, ESP-VID2] are 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 address and ESP-MAC B is the same as remote MEP's local MEP's MAC address and ESP-MAC B is the same as remote MEP's
MAC address. The GMPLS Ethernet Label format, as defined in MAC address. The GMPLS Ethernet Label format, as defined in
[RFC6060], consists of the ESP-MAC DA and ESP-VID. Hence the [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 the Ethernet Labels (i.e., carried in the downstream and from the 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 only, which MEPs need to be provisioned with the VLAN identifiers only, which
can be derived similarly from the Ethernet Labels. can be derived similarly from the Ethernet Labels.
Based on the procedures described in [RFC6060] for bidirectional Based on the procedures described in [RFC6060] for bidirectional PBB-
PBB-TE Ethernet LSP establishment, the Ethernet OAM configuration TE Ethernet LSP establishment, the Ethernet OAM configuration
procedures are recommended as follows: procedures are as follows:
When the RSVP-TE signaling is initiated for the bidirectional When the RSVP-TE signaling is initiated for the bidirectional
Ethernet LSP the local node generates a Path message and: Ethernet LSP the local node generates a Path message and:
o Allocates an Upstream Label formed by combining its MAC address o Allocates an Upstream Label formed by combining its MAC address
(ESP-MAC A) and locally selected VID (ESP-VID1), which will be (ESP-MAC A) and locally selected VID (ESP-VID1), which will be
used to receive traffic; used to receive traffic;
o MUST include the OAM Configuration TLV with OAM Type set to o MUST include the OAM Configuration TLV with OAM Type set to
Ethernet OAM in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES Ethernet OAM in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES
skipping to change at page 9, line 37 skipping to change at page 7, line 37
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, OAM technology/method should be used for the LSP. In this document,
a new OAM Type: Ethernet OAM is defined. IANA is requested to a new OAM Type: Ethernet OAM is defined. IANA is requested to
allocate OAM Type 1 for Ethernet OAM in the RSVP-TE OAM Configuration allocate OAM Type 1 for Ethernet OAM in the RSVP-TE OAM Configuration
Registry. Registry.
RSVP-TE OAM Configuration Registry RSVP-TE OAM Configuration Registry
OAM Type Description OAM Type Description
------------ ------------------ ------------ ------------------
1 Ethernet OAM TBA1 Ethernet OAM
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 Sub-TLV. Configuration Sub-TLV.
3.3. Ethernet OAM Configuration Sub-TLV 3.3. Ethernet OAM Configuration Sub-TLV
The Ethernet OAM Configuration Sub-TLV (depicted below) is defined The Ethernet OAM Configuration Sub-TLV (depicted below) is defined
for Ethernet OAM specific configuration parameters. The Ethernet OAM for Ethernet OAM specific configuration parameters. The Ethernet OAM
Configuration Sub-TLV, when used, MUST be carried in the OAM Configuration Sub-TLV, when used, MUST be carried in the OAM
Configuration TLV. This new sub-TLV accommodates Ethernet OAM Configuration TLV. This new sub-TLV accommodates Ethernet OAM
information and carries sub-TLVs. 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 (32) (IANA) | Length | | Type (TBA2) (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 Sub-TLV. Type: indicates a new type: the Ethernet OAM Configuration Sub-TLV.
IANA is requested to assign a value (32) from the "Sub-TLV" space in IANA is requested to assign a value from the "Sub-TLV" space in the
the "RSVP-TE OAM Configuration Registry". "RSVP-TE OAM Configuration Registry".
Length: indicates the total length including sub-TLVs. Length: indicates the total length of the TLV including padding and
including the Type and Length fields.
Version: identifies the CFM protocol version according to Version: identifies the CFM protocol version according to
[IEEE.802.1Q-2011]. If a node does not support a specific CFM [IEEE.802.1Q-2011]. If a node does not support a specific CFM
version an error MUST be generated: "OAM Problem/Unsupported OAM version an error MUST be generated: "OAM Problem/Unsupported OAM
Version" Version"
MD L. (MD Level): indicates the desired MD Level. Possible values MD L. (MD Level): indicates the desired MD Level. Possible values
are defined according to [IEEE.802.1Q-2011]. If a node does not are defined according to [IEEE.802.1Q-2011]. If a node does not
support a specific MD Level an error MUST be generated: "OAM Problem/ support a specific MD Level an error MUST be generated: "OAM Problem/
Unsupported MD Level". Unsupported MD Level".
3.3.1. MD Name Sub-TLV 3.3.1. MD Name Sub-TLV
The optional MD Name Sub-TLV is depicted below, it MAY be used for MD The optional MD Name Sub-TLV is depicted below, it MAY be used for MD
naming. naming.
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) (IANA) | 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 is requested to maintain an Ethernet Type: 1, MD Name Sub-TLV. IANA is requested to maintain an Ethernet
TLV Type space in the "RSVP-TE OAM Configuration Registry" for the TLV Type space in the "RSVP-TE OAM Configuration Registry" for the
sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV. sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV.
Length: indicates the total length of the TLV including padding. Length: indicates the total length of the TLV including padding and
including the Type and Length fields.
Format: according to [IEEE.802.1Q-2011]. Format: according to [IEEE.802.1Q-2011].
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.
If an undefined Format is specified an error MUST be generated: "OAM If an undefined Format is specified an error MUST be generated: "OAM
skipping to change at page 11, line 36 skipping to change at page 9, line 40
present in the Ethernet OAM Configuration Sub-TLV. present in the Ethernet OAM Configuration Sub-TLV.
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) (IANA) | 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 is requested to maintain an Type: 2, Short MA Name Sub-TLV. IANA is requested to maintain an
Ethernet TLV Type space in the "RSVP-TE OAM Configuration Registry" Ethernet TLV Type space in the "RSVP-TE OAM Configuration Registry"
for the sub-TLV types carried in the Ethernet OAM Configuration Sub- for the sub-TLV types carried in the Ethernet OAM Configuration Sub-
TLV. TLV.
Length: indicates the total length of the TLV including padding. Length: indicates the total length of the TLV including padding and
including the Type and Length fields.
Format: according to [IEEE.802.1Q-2011]. Format: according to [IEEE.802.1Q-2011].
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.
If an undefined Format is specified an error MUST be generated: "OAM If an undefined Format is specified an error MUST be generated: "OAM
skipping to change at page 12, line 21 skipping to change at page 10, line 28
Name MUST uniquely identify a Maintenance Association. 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, this sub-TLV MUST be present in The MEP ID Sub-TLV is depicted below, this sub-TLV MUST be present in
the Ethernet OAM Configuration Sub-TLV. the Ethernet OAM Configuration Sub-TLV.
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) (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 is requested to maintain an Ethernet Type: 3, MEP ID Sub-TLV. IANA is requested to maintain an Ethernet
TLV Type space in the "RSVP-TE OAM Configuration Registry" for the TLV Type space in the "RSVP-TE OAM Configuration Registry" for the
sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV. sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV.
Length: indicates the total length of the TLV including padding. Length: indicates the total length of the TLV including padding and
including the Type and Length fields.
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
only unique within the scope of the MAID. only unique within the scope of the MAID.
skipping to change at page 13, line 18 skipping to change at page 11, line 25
| Type (4) (IANA) | Length | | Type (4) (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prio | CCM I | Reserved (set to all 0s) | | Prio | CCM I | Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 4, Continuity Check (CC) Sub-TLV. IANA is requested to Type: 4, Continuity Check (CC) Sub-TLV. IANA is requested to
maintain an Ethernet TLV Type space in the "RSVP-TE OAM Configuration maintain an Ethernet TLV Type space in the "RSVP-TE OAM Configuration
Registry" for the sub-TLV types carried in the Ethernet OAM Registry" for the sub-TLV types carried in the Ethernet OAM
Configuration Sub-TLV. Configuration Sub-TLV.
Length: indicates the total length of the TLV including padding and
including the Type and Length fields.
Prio: Indicates the priority to be set for CCM frames. In Ethernet, Prio: Indicates the priority to be set for CCM frames. In Ethernet,
3 bits carried in VLAN TAGs identify priority information. Setting 3 bits carried in VLAN TAGs identify priority information. Setting
the priority is optional, all zeros will result in the use of default the priority is optional. If the most significant bit is set to
values as defind in the network nodes. zero, the subsequent 3 priority bits will be ignored, and priority
bits of the Ethernet CCM frame will be set based on default values
specified in the Ethernet nodes. If the most significant bit is set
to 1, the subsequent 3 bits will be used to set the priority bits of
the Ethernet CCM frame.
CCM I (CCM Interval): CCM Interval, it MUST be set according to the 3 CCM I (CCM Interval): CCM Interval, it MUST be set according to the 3
bit encoding [IEEE.802.1Q-2011] shown in Table 1. If a node does not bit encoding [IEEE.802.1Q-2011] shown in Table 1. As a consequence
support the requested CCM Interval an error MUST be generated: "OAM the most significant bit will be set to 0. Four bits are allocated
Problem/Unsupported CC Interval". to support the configuration of CCM intervals that may be specified
in the future. If a node does not support the requested CCM Interval
an error MUST be generated: "OAM Problem/Unsupported CC Interval".
3.4. Pro-active Performance Monitoring 3.4. Pro-active Performance Monitoring
Ethernet OAM functions for Performance Monitoring (PM) allow Ethernet OAM functions for Performance Monitoring (PM) allow
measurements of different performance parameters including Frame Loss measurements of different performance parameters including Frame Loss
Ratio, Frame Delay and Frame Delay variation as defined in Ratio, Frame Delay and Frame Delay variation as defined in
[ITU-T.Y.1731-2011]. Only a subset of PM functions are operated in a [ITU-T.Y.1731-2011]. Only a subset of PM functions are operated in a
pro-active fashion to monitor the performance of the connection pro-active fashion to monitor the performance of the connection
continuously. Pro-active PM supports Fault Management functions, by continuously. Pro-active PM supports Fault Management functions, by
providing an indication of decreased service performance and as such providing an indication of decreased service performance and as such
skipping to change at page 15, line 7 skipping to change at page 13, line 7
o The combined length of MD Name and Short MA Name must be less or o 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 generated: equal to 44bytes, if this is violated an error MUST be generated:
"OAM Problem/Name Length Problem". "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 the Ethernet OAM Configuration Sub-TLV to be 4.1. RSVP-TE OAM Configuration Registry
carried in the OAM Configuration TLV in LSP_ATTRIBUTES and
LSP_REQUIRED_ATTRIBUTES objects in Path and Resv messages.
IANA is requested to allocate the value 1 for Ethernet OAM from the [OAM-CONF-FWK] includes a request for IANA to create the "RSVP-TE OAM
OAM Type space in the "RSVP-TE OAM Configuration Registry" and Configuration Registry". IANA is requested to assign an "OAM Type"
allocate type 32 for the Ethernet OAM Configuration Sub-TLV from the from this registry as follows. Allocate the value TBA1 for "Ethernet
Sub-TLV space in the "RSVP-TE OAM Configuration Registry". OAM" from the "OAM Type Sub-Registry" of the "RSVP-TE OAM
Configuration Registry". Allocate type TBA2 for the "Ethernet OAM
Configuration Sub-TLV" from the technology-specific range of the "OAM
Sub-TLVs Sub-Registry" of the "RSVP-TE OAM Configuration Registry".
RSVP-TE OAM Configuration Registry RSVP-TE OAM Configuration Registry
OAM Type Description OAM Types Sub-Registry
------------ ------------------
1 Ethernet OAM
Sub-TLV Type Description OAM Type Number | Description | Reference
------------ ------------------------------------ -------------------------------------------------
32 Ethernet OAM Configuration Sub-TLV TBA1 | Ethernet OAM | [This.ID]
IANA is requested to maintain an Ethernet TLV Type space in the OAM Sub-TLVs Sub-Registry
"RSVP-TE OAM Configuration Registry" for the sub-TLV types carried in
the Ethernet OAM Configuration Sub-TLV. This document defines the
following types.
Ethernet TLV Type Description Sub-TLV Type | Description | Ref.
----------------- ------------------------------------ ----------------------------------------------------------
0 Reserved TBA2 |Ethernet OAM Configuration Sub-TLV|[This.ID]
1 MD Name Sub-TLV
2 Short MA Name Sub-TLV
3 MEP ID Sub-TLV
4 Continutiy Check Sub-TLV
5- Reserved
The following values need to be assigned under the "OAM Problem" The value of 1 is suggested for TBA1. The value of 32 is suggested
Error Code: "Unsupported OAM Version", "Unsupported MD Level", for TBA2.
"Unknown MD Name Format", "Unknown MA Name Format", "Name Length
Problem", "Unsupported CC Interval". 4.2. Ethernet Sub-TLVs Sub-Registry
IANA is requested to maintain an Ethernet Sub-TLVs Sub-Registry in
the "RSVP-TE OAM Configuration Registry" for the sub-TLV types
carried in the Ethernet OAM Configuration Sub-TLV. This document
defines the following types.
Ethernet Sub-TLVs Sub-Registry
Range | Registration Procedures
------------+----------------------------
0-65534 | IETF Review
65535-65536 | Experimental
Sub-TLV Type | Description | Ref.
---------------------------------------------------
0 | Reserved | [This.ID]
1 | MD Name Sub-TLV | [This.ID]
2 | Short MA Name Sub-TLV | [This.ID]
3 | MEP ID Sub-TLV | [This.ID]
4 | Continuity Check Sub-TLV | [This.ID]
5-65536 | Unassigned | [This.ID]
4.3. RSVP Error Code
[OAM-CONF-FWK] includes a request for IANA to allocate a new Error
Code, "OAM Problem" in the "Error Codes and Globally-Defined Error
Value Sub-Codes" sub-registry of the "Resource Reservation Protocol
(RSVP) Parameters" registry. [OAM-CONF-FWK] defines a set of Error
Value sub-codes for the "OAM Problem" Error Code. This document
defines additional Error Values sub-codes for the "OAM Problem" Error
Code as defined below.
Value | Description | Reference
-------+---------------------------+--------------
TBA | Unsupported OAM Version | [This.ID]
TBA | Unsupported MD Level | [This.ID]
TBA | Unknown MD Name Format | [This.ID]
TBA | Unknown MA Name Format | [This.ID]
TBA | Name Length Problem | [This.ID]
TBA | Unsupported CC Interval | [This.ID]
5. Security Considerations 5. Security Considerations
This document does not introduce any additional security issue to This document does not introduce any additional security issue to
those discussed in [OAM-CONF-FWK] and [RFC6060]. those discussed in [OAM-CONF-FWK] and [RFC6060].
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.
Contributors 7. Contributors
- Don Fedyk - Don Fedyk
- Dinesh Mohan - Dinesh Mohan
7. References 8. References
7.1. Normative References 8.1. Normative References
[IEEE.802.1Q-2011] [IEEE.802.1Q-2011]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks -- Media Access Control (MAC) Bridges and Virtual networks -- Media Access Control (MAC) Bridges and Virtual
Bridged Local Area Networks", IEEE Std 802.1Q, 2011. Bridged Local Area Networks", IEEE Std 802.1Q, 2011.
[OAM-CONF-FWK] [OAM-CONF-FWK]
"OAM Configuration Framework for GMPLS RSVP-TE", Internet Attila Takacs, Don Fedyk, and Jia He, "OAM Configuration
Draft, work in progress. Framework for GMPLS RSVP-TE", Internet Draft, work in
progress, 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs, [RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs,
"Generalized Multiprotocol Label Switching (GMPLS) Control "Generalized Multiprotocol Label Switching (GMPLS) Control
of Ethernet Provider Backbone Traffic Engineering of Ethernet Provider Backbone Traffic Engineering (PBB-
(PBB-TE)", RFC 6060, March 2011. TE)", RFC 6060, March 2011.
7.2. Informative References 8.2. Informative References
[ITU-T.Y.1731-2011] [ITU-T.Y.1731-2011]
ITU, "ITU-T Recommendation Y.1731: OAM functions and ITU, "ITU-T Recommendation Y.1731: OAM functions and
mechanisms for Ethernet based networks", ITU-T mechanisms for Ethernet based networks", ITU-T
Recommendation Y.1731, 2011. Recommendation Y.1731, 2011.
[RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized [RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized
Multiprotocol Label Switching (GMPLS) Ethernet Label Multiprotocol Label Switching (GMPLS) Ethernet Label
Switching Architecture and Framework", RFC 5828, Switching Architecture and Framework", RFC 5828, March
March 2010. 2010.
Authors' Addresses Authors' Addresses
Attila Takacs Attila Takacs
Ericsson Ericsson
Konyves Kalman krt. 11. Konyves Kalman krt. 11.
Budapest, 1097 Budapest 1097
Hungary Hungary
Email: attila.takacs@ericsson.com Email: attila.takacs@ericsson.com
Balazs Peter Gero Balazs Peter Gero
Ericsson Ericsson
Konyves Kalman krt. 11. Konyves Kalman krt. 11.
Budapest, 1097 Budapest 1097
Hungary Hungary
Email: balazs.peter.gero@ericsson.com Email: balazs.peter.gero@ericsson.com
Hao Long Hao Long
Huawei Huawei
Email: lonho@huawei.com Email: lonho@huawei.com
 End of changes. 52 change blocks. 
106 lines changed or deleted 152 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/