draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-05.txt   draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-06.txt 
Network Working Group A. Kern Network Working Group A. Kern
Internet-Draft A. Takacs Internet-Draft A. Takacs
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: March 2013 September 2012 Expires: May 14, 2014 November 10, 2013
GMPLS RSVP-TE Extensions for SONET/SDH and OTN OAM Configuration GMPLS RSVP-TE Extensions for SONET/SDH and OTN OAM Configuration
draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-05 draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-06
Abstract Abstract
GMPLS has been extended to support connection establishment in both GMPLS has been extended to support connection establishment in both
SONET/SDH [RFC4606] and OTN [RFC4328] networks. However support for SONET/SDH and OTN networks. However support for the configuration of
the configuration of the supervision functions is not specified. the OAM functions is not specified. Both SONET/SDH and OTN implement
Both SONET/SDH and OTN implement supervision functions to qualify the OAM functions to monitor the transported signals. This document
transported signals. This document defines extensions to RSVP-TE for defines extensions to RSVP-TE for SONET/SDH and OTN OAM configuration
SONET/SDH and OTN OAM configuration based on the OAM Configuration based on the OAM Configuration Framework defined in a separate
Framework defined in [GMPLS-OAM-FWK]. document. This document supports, but does not modify, 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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [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 March 2013. This Internet-Draft will expire on May 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of SONET/SDH and OTN OAM related functions . . . . . 5 2. Overview of SONET/SDH and OTN OAM related functions . . . . . 3
2.1. Continuity supervision . . . . . . . . . . . . . . . . . . 5 2.1. Continuity supervision . . . . . . . . . . . . . . . . . 3
2.2. Connectivity supervision . . . . . . . . . . . . . . . . . 5 2.2. Connectivity supervision . . . . . . . . . . . . . . . . 3
2.2.1. SONET/SDH . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. SONET/SDH . . . . . . . . . . . . . . . . . . . . . . 4
2.2.2. OTN . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.2. OTN . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Signal quality supervision . . . . . . . . . . . . . . . . 6 2.3. Signal quality supervision . . . . . . . . . . . . . . . 4
2.3.1. SONET/SDH . . . . . . . . . . . . . . . . . . . . . . 6 2.3.1. SONET/SDH . . . . . . . . . . . . . . . . . . . . . . 4
2.3.2. OTN . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.2. OTN . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Delay measurement . . . . . . . . . . . . . . . . . . . . 6 2.4. Delay measurement . . . . . . . . . . . . . . . . . . . . 5
3. RSVP-TE signaling extensions . . . . . . . . . . . . . . . . . 7 3. RSVP-TE signaling extensions . . . . . . . . . . . . . . . . 5
3.1. Operation overview . . . . . . . . . . . . . . . . . . . . 7 3.1. Operation overview . . . . . . . . . . . . . . . . . . . 5
3.1.1. Continuity Check supervision . . . . . . . . . . . . . 7 3.1.1. Continuity Check supervision . . . . . . . . . . . . 6
3.1.2. Connectivity Monitoring supervision . . . . . . . . . 8 3.1.2. Connectivity Monitoring supervision . . . . . . . . . 6
3.1.2.1. SDH/SONET . . . . . . . . . . . . . . . . . . . . 8 3.1.2.1. SDH/SONET . . . . . . . . . . . . . . . . . . . . 6
3.1.2.2. OTN . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.2.2. OTN . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.3. Signal quality supervision . . . . . . . . . . . . . . 9 3.1.3. Signal quality supervision . . . . . . . . . . . . . 7
3.2. Signaling support of Virtual Concatenation Groups (VCG) . 9 3.2. Signaling support of Virtual Concatenation Groups (VCG) . 8
3.3. OAM types and functions . . . . . . . . . . . . . . . . . 10 3.3. OAM types and functions . . . . . . . . . . . . . . . . . 8
3.4. SONET/SDH OAM Configuration sub-TLV . . . . . . . . . . . 10 3.4. SONET/SDH OAM Configuration Sub-TLV . . . . . . . . . . . 9
3.5. OTN OAM Configuration sub-TLV . . . . . . . . . . . . . . 11 3.5. OTN OAM Configuration Sub-TLV . . . . . . . . . . . . . . 9
3.6. TTI Configuration Sub-TLV . . . . . . . . . . . . . . . . 11 3.6. SDH TTI Configuration Sub-TLV . . . . . . . . . . . . . . 9
3.6.1. SDH TTI Configuration Sub-TLV . . . . . . . . . . . . 11 3.7. OTN TTI Configuration Sub-TLV . . . . . . . . . . . . . . 10
3.6.2. OTN TTI Configuration Sub-TLV . . . . . . . . . . . . 12 3.8. Degraded Signal Thresholds Sub-TLV . . . . . . . . . . . 12
3.7. Degraded signal thresholds Sub-TLV . . . . . . . . . . . . 14 4. Error handling . . . . . . . . . . . . . . . . . . . . . . . 13
4. Error handling . . . . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Both SONET/SDH and OTN implement supervision functions to qualify the Both SONET/SDH and OTN implement OAM functions to monitor the
transported signals. Supervision functions include continuity, transported signals. Supervision functions include continuity,
connectivity, signal quality, alignment and payload supervision. The connectivity, signal quality, alignment and payload supervision. The
ITU-T G.806 [G.806] recommendation defines the generic framework of ITU-T G.806 [G.806] recommendation defines the generic framework of
the supervision functions, which are then further specified for the supervision functions, which are then further specified for SONET
SONET/SDH and OTN in technology specific documents. /SDH and OTN in technology specific documents.
GMPLS has been extended to support connection establishment in SONET/ GMPLS has been extended to support connection establishment in SONET/
SDH [RFC4606], OTN [RFC4328] and OTNv3 [OTNv3_SIG] networks. These SDH [RFC4606], and in OTN [RFC4328] [RFC6344] networks. These
documents however do not support the configuration of the respective documents however do not support the configuration of the respective
supervision functions. OAM supervision functions.
[GMPLS-OAM-FWK] defines a technology-agnostic framework for GMPLS to [I-D.ietf-ccamp-oam-configuration-fwk] defines a technology-agnostic
support the establishment and configuration of the pro-active OAM framework for GMPLS to support the establishment and configuration of
functions of signalled connections. The properties of the OAM the pro-active OAM functions of signaled connections. The properties
functions are exchanged during connection establishment and may be of the OAM functions are exchanged during connection establishment
modified during the life of the connection. The technology specific and may be modified during the life of the connection. The
parameters to be exchanged are to be described in accompanying technology specific parameters to be exchanged are to be described in
documents. This document defines the extensions for SONET/SDH and accompanying documents. This document defines the extensions for
OTN OAM configuration for end-to-end monitoring. SONET/SDH and OTN OAM configuration for end-to-end monitoring.
2. Overview of SONET/SDH and OTN OAM related functions 2. Overview of SONET/SDH and OTN OAM related functions
SONET/SDH [G.707] and OTN [G.709v3] provide a variety of supervision SONET/SDH [G.707] and OTN [G.709] provide a variety of supervision
functions. Among these functions we consider continuity, functions. Among these functions we consider continuity,
connectivity and signal quality supervision functions, as these are connectivity and signal quality supervision functions, as these are
the candidates for GMPLS based configuration. We also consider delay the candidates for GMPLS based configuration. We also consider delay
measurement management function of OTN. measurement functionality for OTN. The reader should refer to the
ITU-T documents for additional information. Familiarity with GMPLS,
SONET/SDH and OTN terminology is assumed.
2.1. Continuity supervision 2.1. Continuity supervision
Continuity supervision provides methods monitoring the health of a Continuity supervision provides methods for monitoring the health of
connection (trail). a connection (trail).
2.2. Connectivity supervision 2.2. Connectivity supervision
The connectivity supervision function provides a method to detect The connectivity supervision function provides a method to detect
misconnections. The detection procedure is based on emitting a Trace misconnections. The detection procedure is based on a Trace Trail
Trail Identifier (TTI) known by both endpoints. The TTI is included Identifier (TTI) known by both endpoints. The TTI is included by the
by the source node as an overhead signal for each connection. The source node as an overhead signal for each connection. The receiver
receiver node then compares the received TTI with the expected value node then compares the received TTI with the expected value and
and decides if a miss-connection occurred. determines if a mis-connection occurred.
2.2.1. SONET/SDH 2.2.1. SONET/SDH
In case of SONET/SDH, connectivity supervision is implemented in the In case of SONET/SDH, connectivity supervision is implemented in the
Regeneration Section (RS) and in the lower and higher order path Regeneration Section (RS) and in the lower and higher order path
layers (LOVC and HOVC). In all layers the TTI encodes only the layers (LOVC and HOVC). In all layers the TTI encodes only the
Access Point Identifier (API) of the source node. In the various Access Point Identifier (API) of the source node. In the various
layers the lengths of these TTIs are different. In RS the TTI layers, the lengths of these TTIs are different. In RS, the TTI
(encoded in J0 octet) is either 1 or 16 octets long. In higher order (encoded in J0 byte) is either 1 or 16 bytes long. In higher order
paths the TTI (encoded in J1), is either 16 or 64 octet long. In paths the TTI (encoded in J1), is either 16 or 64 bytes long. In
lower order paths the TTI is transmitted in the J2 byte and is 16 lower order paths, the TTI is transmitted in the J2 byte and is 16
octet long. bytes long.
2.2.2. OTN 2.2.2. OTN
In case of OTN, connectivity supervision is supported by the OTUk and In case of OTN, connectivity supervision is supported by the OTUk and
ODUk digital hierarchy layers. In both layers, the length of the TTI ODUk digital hierarchy layers. In both layers, the length of the TTI
is 64 octets, but only the first 32 octets are considered for is 64 bytes, but only the first 32 bytes are considered for
connectivity supervision. This first part is further divided into a connectivity supervision. This first part is further divided into a
Source Access Point Identifier (SAPI) and a Destination Access Point Source Access Point Identifier (SAPI) and a Destination Access Point
Identifier (DAPI). Connectivity supervision may consider either the Identifier (DAPI). Connectivity supervision may consider either the
SAPI or DAPI only or both. The structure of the SAPI and DAPI is SAPI or DAPI only or both. The structure of the SAPI and DAPI is
specified in [G.709]. specified in [G.709].
2.3. Signal quality supervision 2.3. Signal quality supervision
The quality of the transmitted signal is monitored as a ratio of bad The quality of the transmitted signal is monitored as a ratio of bad
frames. If the number of such frames reaches a threshold a defect frames. If the number of such frames reaches a threshold, a defect
state is declared. To detect the correctness of the frames an Error state is declared. To detect the correctness of the frames, an Error
Detection Code (EDC), such as Bit Interleaved Parity (BIP), is used. Detection Code (EDC), such as Bit Interleaved Parity (BIP), is used.
The distribution of the errors is assumed to follow either Poisson or The distribution of the errors is assumed to follow either Poisson or
a bursty distribution. For Poisson distribution an EDC violation a bursty distribution. For Poisson distribution, an EDC violation
ratio is defined as the threshold; while for the bursty model the ratio is defined as the threshold; while for the bursty model, the
threshold is defined as a number of consecutive 1-second time threshold is defined as a number of consecutive 1-second time
intervals in which the EDC violation exceeds a predefined ratio. In intervals in which the EDC violation exceeds a predefined ratio. In
case of Poisson error distribution two defect state levels are case of Poisson error distribution, two defect state levels are
defined: the Excessive Error and Degraded Signal defect. In the case defined: the Excessive Error and Degraded Signal defect. In the case
of the bursty model, only the Degraded Signal defect level is of the bursty model, only the Degraded Signal defect level is
considered. considered.
2.3.1. SONET/SDH 2.3.1. SONET/SDH
SONET/SDH supports both Excessive Error and Degraded Signal defect SONET/SDH supports both Excessive Error and Degraded Signal defect
levels and supports both Poisson and bursty error distribution levels and supports both Poisson and bursty error distribution
models. These signal quality parameters are configured for the models. These signal quality parameters are configured for the
Multiplexing Section (MS) and the LOVC and HOVC path layers. Multiplexing Section (MS) and the LOVC and HOVC path layers.
2.3.2. OTN 2.3.2. OTN
For OTN, in the digital transport layers (OTUk and ODUk), only the
For OTN, in the digital transport layers (OTUk and ODUk) only the bursty error distribution model with the Degraded Signal defect level
bursty error distribution model errors with the Degraded Signal is supported. Two parameters are defined: Ratio of the bad frames in
defect level is supported. Two parameters are defined: Ratio of the a one second interval (0% to 100% or 0 to number of frames per
bad frames in a one second interval (0% to 100% or 0 to number of 1-second interval) and Number of consecutive intervals (between 2 and
frames per 1-second interval) and Number of consecutive intervals 10). Signal quality supervision in the optical transport layers is
(between 2 and 10). Signal quality supervision in the optical not specified by [G.798], it is indicated to be for further study.
transport layers is not specified by [G.798], it is indicated to be
for further study.
2.4. Delay measurement 2.4. Delay measurement
[G.709v3] introduced a tool for measuring round-trip delay of a [G.709] introduced a tool for measuring round-trip delay of a
bidirectional ODU path or tandem connection. For implementing delay bidirectional ODU path or tandem connection. For implementing delay
measurement a one-bit delay measurement (DM) signal is defined in the measurement, a one-bit delay measurement (DM) signal is defined in
ODUk header. That signal is constant value (either 0 or 1). One the ODUk header. That signal bit is a constant value (either 0 or
endpoint initiates a delay measurement by inverting the bit emitted 1). One endpoint initiates a delay measurement by inverting the bit
in the DM signal. The remote endpoint loops back the DM signal; emitted in the DM signal. The remote endpoint loops back the DM
therefore, the delay measurement initiating node will receive the signal; therefore, the delay measurement initiating node will receive
inverted signal from the remote endpoint. This way the initiating the inverted signal from the remote endpoint. This way the
endpoint will determine the round trip delay. initiating endpoint will determine the round trip delay.
3. RSVP-TE signaling extensions 3. RSVP-TE signaling extensions
3.1. Operation overview 3.1. Operation overview
RFC 4606 and RFC 4328 define the RSVP-TE extensions necessary to RFC 4328, RFC 4606 and RFC6344 defined the GMPLS RSVP-TE extensions
manage SDH/SONET and OTN optical and digital hierarchy connections. necessary to manage SONET/SDH and OTN optical and digital hierarchy
Connections for recent version of OTN, the OTNv3 are configured connections. The monitoring functions associated to these
according to [OTNv3_SIG]. The monitoring functions associated to connections MAY be configured when configuring the connections.
these connections may be configured together with configuring the
connection itself.
The LSP Attribute Flag "OAM MEP entities desired" [GMPLS-OAM-FWK] is The LSP Attribute Flag "OAM MEP entities desired"
used to signal that the monitoring functions at the endpoints must be [I-D.ietf-ccamp-oam-configuration-fwk] MUST be used to signal that
established. The "OAM MIP entities desired" flag must be set to 0 the monitoring functions at the endpoints MUST be established. The
and must be ignored. "OAM MIP entities desired" flag MUST be set to 0 and MUST be ignored.
To configure OAM parameters the OAM Configuration TLV can be included To configure OAM parameters, the OAM Configuration TLV MAY be
in the LSP_ATTRIBUTES object. The TLV identifies which OAM included in the LSP_ATTRIBUTES object. The TLV identifies which OAM
technology ("OAM Type" field) to be used as well as which OAM technology ("OAM Type" field) to be used as well as which OAM
functions are to be enabled (OAM Function Flags sub-TLV). For SONET/ functions are to be enabled (OAM Function Flags Sub-TLV). For SONET/
SDH and OTN the "Continuity Check" and "Connectivity Verification" SDH and OTN, the "Continuity Check" and "Connectivity Verification"
flags control the Continuity and Connectivity supervision functions, flags control the Continuity and Connectivity supervision functions,
while the "Performance Monitoring/Loss" flag enables the Signal while the "Performance Monitoring/Loss" flag enables the Signal
Quality supervision function. Quality supervision function.
Recent release of OTN [G.709v3] introduced delay measurement for The recent revision of OTN [G.709] introduced delay measurement
paths. Such node enables delay measurement by setting "Performance capability for paths. A node MAY enable delay measurement by setting
Monitoring/Delay" flag. By setting that flag the node also indicates the "Performance Monitoring/Delay" flag. By setting that flag, the
that it will initiate the delay measurement proactively; therefore, node also indicates that it will initiate the delay measurement;
the remote endpoint node should not initate delay measurement over therefore, the remote endpoint node SHOULD NOT initiate delay
the configured connection proactively. Equipments designed according measurement over the configured connection. Equipment designed to
to earlier version of G709 must clear "Performance Monitoring/Loss" earlier versions of G709 MUST clear the "Performance Monitoring/Loss"
flag and upon receiving OAM configuration message with "Performance flag and upon receiving an OAM configuration message with
Monitoring/Delay" flag set must generate "OAM Problem/Unsupported OAM "Performance Monitoring/Delay" flag set MUST generate "OAM Problem/
Function" error. The "Performance Monitoring/Delay" flag must be Unsupported OAM Function" error. The "Performance Monitoring/Delay"
cleared for SONET/SDH as it is not supported by SONET/SDH. flag MUST be cleared for SONET/SDH as it is not supported by SONET/
SDH.
For additional details the appropriate technology specific sub-TLV For additional details, the appropriate technology specific sub-TLV
can be carried in the OAM Configuration TLV. MAY be carried in the OAM Configuration TLV.
3.1.1. Continuity Check supervision 3.1.1. Continuity Check supervision
In case of both discussed technologies, setting up continuity In case of both SONET/SDN and OTN technologies, setting up the
supervision function for a connection does not need further continuity supervision function for a connection does not need
configuration besides enabling it. Therefore, by setting the further configuration besides enabling it. Therefore, by setting the
"Connectivity Monitoring" Flag of OAM Function implicitly enables the "Connectivity Monitoring" Flag of OAM Function implicitly enables the
continuity supervision function as well. continuity supervision function as well.
3.1.2. Connectivity Monitoring supervision 3.1.2. Connectivity Monitoring supervision
3.1.2.1. SDH/SONET 3.1.2.1. SDH/SONET
[G.707] defines three bytes (signals) for connectivity supervision [G.707] defines three TTI overhead bytes (signals) for connectivity
purposes: the J0 byte in RS layer, the J1 and J2 bytes in HOVC and supervision: the J0 byte in RS layer, the J1 byte in the HOVC layer
LOVC layers. These bytes encode 1 octet, 16 octet or 64 octet long and the J2 byte in the LOVC layer. The source node transmits the TTI
unstructured octet streams. The source node emits this stream and and the destination node matches it with the expected one. When the
the destination node matches it with an expected one. When the destination detects mismatch, a defect state will be declared.
destination detects mismatch, defect state will be declared.
Since these streams encode an identifier defined for the source node, Since these bytes encode a TTI identifier defined for the source
different stream will to be emitted in the upstream and downstream node, different stream will be emitted in the upstream and downstream
directions for bidirectional connections. During the configuration directions for bidirectional connections. During the configuration
the egress node has to be configured with the TTI value to be the downstream (destination) node has to be configured with the TTI
expected in the downstream direction and the TTI value to be emitted value to be expected in the downstream direction and the TTI value to
in the upstream direction. Therefore the SONET/SDH OAM Configuration be emitted in the upstream direction. Therefore, the SONET/SDH OAM
TLV carries two Connectivity Supervision TLVs. Configuration TLV carries two Connectivity Supervision TLVs.
3.1.2.2. OTN 3.1.2.2. OTN
[G.709] defines a 64 octet long TTI, where the first 32 octets have a [G.709] defines a 64 byte long TTI format, where the first 32 bytes
generic structure: a zero octet, a 15 octet long SAPI, a second zero have a generic structure: a zero byte, a 15 bytes long SAPI, a second
octet and finally the 15 octet long DAPI. zero byte and finally the 15 bytes long DAPI format.
For a unidirectional connection a single Connection Supervision TLV For a unidirectional connection, a single Connection Supervision TLV
encodes elements of the TTI to be emitted. This TLV also specifies encodes elements of the TTI to be emitted. This TLV also specifies
which parts of the TTI are compared to the expected values (only which parts of the TTI are compared to the expected values (only
SAPI, only DAPI, both SAPI and DAPI). SAPI, only DAPI, both SAPI and DAPI).
In case of a bidirectional connection an endpoint can use a common In case of a bidirectional connection an endpoint can use a common
API value for SAPI (for transmitted signal) and DAPI (for received API value for SAPI (for transmitted signal) and DAPI (for received
signal). (See Figure 1.) The TTI values used in downstream and signal). (See Figure 1.) The TTI values used in downstream and
upstream directions are derived from the two API values: the upstream directions are derived from the two API values: the
downstream TTI will have the form of [0, API_a, 0, API_z] while the downstream TTI will have the form of [0, API_a, 0, API_z] while the
upstream TTI will use the form of [0, API_z, 0 API_a]. upstream TTI will use the form of [0, API_z, 0 API_a].
skipping to change at page 9, line 25 skipping to change at page 7, line 44
( API_a1 ) TTI_upstream = [0, API_z1, 0, API_a1 ] ( API_z1 ) ( API_a1 ) TTI_upstream = [0, API_z1, 0, API_a1 ] ( API_z1 )
| Rx port | -- < -- < -- < -- < -- < -- < -- < -- < -- | Tx Port | | Rx port | -- < -- < -- < -- < -- < -- < -- < -- < -- | Tx Port |
| Tx port | -- > -- > -- > -- > -- > -- > -- > -- > -- | Rx Port | | Tx port | -- > -- > -- > -- > -- > -- > -- > -- > -- | Rx Port |
( API_a2 ) TTI_downstream = [0, API_a2, 0, API_z2 ] ( API_z2 ) ( API_a2 ) TTI_downstream = [0, API_a2, 0, API_z2 ] ( API_z2 )
Figure 2: TTI construction when dedicated APIs identify the receiver Figure 2: TTI construction when dedicated APIs identify the receiver
and transmitter interfaces and transmitter interfaces
3.1.3. Signal quality supervision 3.1.3. Signal quality supervision
Signal quality supervision function is implemented in MS, HOVC, LOVC Signal quality supervision function is implemented in the MS, HOVC,
layers of SDH/SONET. All three layers support exceeded error level LOVC layers of SONET/SDH. All three layers support exceeded error
with Poisson error distribution model and degraded signal defect level with Poisson error distribution model and degraded signal
level with both, Poisson and bursty error distribution model. defect level with both of the Poisson and bursty error distribution
Dedicated Signal quality supervision TLVs encode each level, models. Dedicated Signal quality supervision TLVs encode each level,
therefore when the "Performance Monitoring/Loss" flag is set; several therefore when the "Performance Monitoring/Loss" flag is set; several
such TLVs can be added to the SONET/SDH OAM Configuration TLV. If a such TLVs MAY be added to the SONET/SDH OAM Configuration TLV. If a
configuration TLV for a particular level is missing the default configuration TLV for a particular level is missing, the default
parameters for that level is to be applied. parameters for that level SHOULD be applied.
The OTN supports only Degraded Signal defect with bursty error model OTN supports only Degraded Signal defect with bursty error model in
in OTUk and ODUk layers. Thus, the only parameters to be encoded OTUk and ODUk layers. Thus, the only parameters to be encoded are:
are: the threshold for bad frames in a 1-second interval and the the threshold for bad frames in a 1-second interval and the number of
number of consecutive 1-second intervals with excessive bad frames. consecutive 1-second intervals with excessive bad frames.
Furthermore, as only one level is allowed a single Signal quality Furthermore, as only one level is allowed, a single Signal quality
supervision TLV is added to the OTN OAM Configuration TLV. supervision TLV MAY be added to the OTN OAM Configuration TLV.
3.2. Signaling support of Virtual Concatenation Groups (VCG) 3.2. Signaling support of Virtual Concatenation Groups (VCG)
A key capability of both, SONET/SDH and OTN is the support of virtual A capability of both SONET/SDH and OTN is the support of virtual
concatenation. This inverse multiplexing method uses multiplicity of concatenation. This inverse multiplexing method uses multiplicity of
parallel basic signals. The supervision function parameters of these parallel individual signals. The supervision function parameters of
basic signals can be different. these basic signals can be different.
[RFC6344] summarises GMPLS signaling capabilities to support virtual [RFC6344] describes GMPLS signaling capabilities to support virtual
concatenation and proposes extensions to that. A Virtual concatenation. A Virtual Concatenated Group (VCG) is constructed
Concatenated Group (VCG) is constructed from several individual data from several individual data plane signals. The co-routed signals of
plane signals. The co-routed signals of a VCG could be provisioned a VCG may be provisioned together using a single RSVP-TE session (co-
together using a single RSVP-TE session (co-signaled). As different signaled). As different OAM configuration may be applied to each of
OAM configuration may be applied to each of these individual signals, these individual signals, the OAM configuration extension is applied
the OAM configuration extension is applied as follows. as follows.
We assume that the same OAM type and the same set of OAM functions We assume that the same OAM type and the same set of OAM functions
apply to every individual signal of the VCG. A single OAM apply to each individual signal of the VCG. A single OAM
Configuration TLV is carried in the LSP_ATTRIBUTES Object, while Configuration TLV MUST be carried in the LSP_ATTRIBUTES Object, while
multiple instances of technology specific OAM configuration sub-TLVs multiple instances of technology specific OAM configuration sub-TLVs
are added: one instance per individual signal. The order of these MAY be added: one instance per individual signal. The order of these
TLVs refers to the logical order of the basic signals (as they are TLVs references the logical order of the individual signals (as they
listed in the Label Object). are listed in the Label Object).
[RFC6344] allows extension/pruning of a VCG. To achieve it the [RFC6344] allows extension/pruning of a VCG. To achieve it, the
traffic descriptor, which encodes how the VCG is structured, in the traffic descriptor, which encodes how the VCG is structured, in the
RSVP-TE session is updated. If the VCG is updated the contents of RSVP-TE session is updated. If the VCG is updated, the contents of
the OAM Configuration TLV needs to be updated accordingly. the OAM Configuration TLV MUST be updated accordingly.
3.3. OAM types and functions 3.3. OAM types and functions
This document defines two new code points for the "OAM Type" field of This document defines two new code points for the "OAM Type" field of
the OAM Configuration TLV, defined in [GMPLS-OAM-FWK]: SONET/SDH OAM the OAM Configuration TLV, defined in
and OTN Digital Hierarchy OAM. [I-D.ietf-ccamp-oam-configuration-fwk]: SONET/SDH OAM and OTN Digital
Hierarchy OAM.
OAM Type Description
------------ ------------------
3 SONET/SDH OAM
4 OTN Digital Hierarchy OAM
The "OAM Function Flags sub-TLV", defined in [GMPLS-OAM-FWK]. SONET/ The "OAM Function Flags Sub-TLV" is defined in
SDH and OTN supervision functions are defined in this document for [I-D.ietf-ccamp-oam-configuration-fwk]. SONET/SDH and OTN
the following flags: "Continuity Check", "Connectivity Verification", supervision functions are defined in this document for the following
"Performance Monitoring/Loss" and "Performance Monitoring/Delay". flags: "Continuity Check", "Connectivity Verification", "Performance
Monitoring/Loss" and "Performance Monitoring/Delay".
3.4. SONET/SDH OAM Configuration sub-TLV 3.4. SONET/SDH OAM Configuration Sub-TLV
SONET/SDH OAM Configuration sub-TLV is defined to encode the SONET/SDH OAM Configuration Sub-TLV is defined to encode the
parameters of continuity, connectivity and signal quality supervision parameters of continuity, connectivity and signal quality supervision
functions for SONET/SDH networks. functions for SONET/SDH networks.
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 (34) (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ sub TLVs ~ ~ sub TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: indicates a new type: the SONET/SDH OAM Configuration TLV (IANA Type: indicates a new type: the SONET/SDH OAM Configuration TLV (IANA
to define). to define).
Length: indicates the total length including sub-TLVs Length: indicates the total length including sub-TLVs
3.5. OTN OAM Configuration sub-TLV 3.5. OTN OAM Configuration Sub-TLV
OTN OAM Configuration TLV is defined to encode the parameters of OTN OAM Configuration TLV is defined to encode the parameters of
continuity, connectivity and signal quality supervision functions for continuity, connectivity and signal quality supervision functions for
OTN. OTN.
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 (5) (IANA) | Length | | Type (35) (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ sub TLVs ~ ~ sub TLVs ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: indicates a new type: the OTN OAM Configuration TLV (IANA to Type: indicates a new type: the OTN OAM Configuration TLV (IANA to
define). define).
Length: indicates the total length including sub-TLVs Length: indicates the total length including sub-TLVs
3.6. TTI Configuration Sub-TLV 3.6. SDH TTI Configuration Sub-TLV
This sub-TLV is carried in the SONET/SDH OAM Configuration Sub-TLV,
3.6.1. SDH TTI Configuration Sub-TLV if the Connectivity Verification OAM Function Flag is set. In each
supporting layer, the TTI identifies the source interface (SAPI);
This sub-TLV is carried in the SONET/SDH OAM Configuration sub-TLV, however, the length of this identifier varies layer-by-layer (see
if the Connectivity Verification OAM Function Flag is set. In every
supporting layers the TTI identifies the source interface (SAPI);
however, the length of this identifier varies layer-by-layer (See
Section 2.2.1). Therefore, a generic TLV is defined supporting Section 2.2.1). Therefore, a generic TLV is defined supporting
various TTI lengths. various TTI lengths.
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 (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|U| Reserved | TTI | |A|U| Reserved | TTI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ TTI cont ~ ~ TTI cont ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flag "A", when set enables the AIS insertion on detecting TTI Flag "A", when set enables the AIS insertion when detecting a TTI
mismatch. mismatch.
Flat "U" encodes if the TTI refers to the downstream TTI (U=0) or the Flag "U" encodes if the TTI refers to the downstream node's source
upstream one (U=1). TTI (U=0) or the upstream node's TTI (U=1) (expected TTI).
The TTI field carries the TTI to be transmitted by the source node The TTI field carries the TTI to be transmitted by the source node
and to be expected by the sink. The TLV is padded to 4-octets. and to be expected by the sink. The TLV is padded to 4 bytes.
If the specified length and format of the TTI carried in this TLV is If the specified length and format of the TTI carried in this TLV is
not supported by the referred SONET/SDH layer, error must be not supported by the referenced SONET/SDH layer, an error must be
generated: "OAM Problem/TTI Length Mismatch". generated: "OAM Problem/TTI Length Mismatch".
3.6.2. OTN TTI Configuration Sub-TLV 3.7. OTN TTI Configuration Sub-TLV
This sub-TLV is carried in the OTN OAM Configuration sub-TLV, if the This sub-TLV is carried in the OTN OAM Configuration Sub-TLV, if the
Connectivity Verification OAM Function Flag is set. Connectivity Verification OAM Function Flag is set.
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 = 32 | | Type (IANA) | Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|S|D|APP| Reserved | SAPI | |A|S|D|APP| Reserved | SAPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAPI cont | | SAPI cont |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAPI cont | | SAPI cont |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAPI cont | | SAPI cont |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAPI | DAPI | | SAPI | DAPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DAPI cont | | DAPI cont |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DAPI cont | | DAPI cont |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DAPI cont | | DAPI cont |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Three control flags are defined. Flag "A" indicates that AIS Three control flags are defined. Flag "A" indicates that AIS
insertion on detecting TTI mismatch (failing the connectivity insertion when detecting a TTI mismatch (failing the connectivity
verification) is required (A=1) or not (A=0). The next two flags verification) is required (A=1) or not (A=0). The next two flags
define which parts of the received TTI are compared to the expected define which parts of the received TTI are compared to the expected
one. If flag "S" is set the TTI octets 1 to 15 are matched to the one. If flag "S" is set, the TTI bytes 1 to 15 are matched to the
expected SAPI value. If the flag "D" is set the TTI octets 17 to 31 expected SAPI value. If the flag "D" is set, the TTI bytes 17 to 31
are matched to the expected DAPI value. If both "S" and "D" are set are matched to the expected DAPI value. If both "S" and "D" are set,
both parts of TTI are compared to SAPI and DAPI values. Setting both both parts of TTI are compared to SAPI and DAPI values. Setting both
"S" and "D" bits to 0 is invalid, and if encountered error must be "S" and "D" bits to 0 is invalid, and if encountered, an error must
generated: "OAM Problem/Invalid CC/CV configuration". be generated: "OAM Problem/Invalid CC/CV configuration".
The next two bits "APP" encode the applicability of the TTI The next two bits "APP" encode the applicability of the TTI
configuration and the following code points are defined: configuration and the following code points are defined:
0 - Single TTI configuration: the TTI configuration is done 0 - Single TTI configuration: the TTI configuration is done
according only to this TLV and no further TTI configuration TLVs according only to this TLV and no further TTI configuration TLVs
are expected. This code point is used for unidirectional are expected. This code point is used for unidirectional
connections and for bidirectional connections with common APIs connections and for bidirectional connections with common APIs
(See Figure 1) (See Figure 1)
1 - Downstream TTI for double TTI configuration: the current TLV 1 - Downstream TTI for double TTI configuration: the current TLV
instruct the configuration of the TTI to be used in downstream instructs the configuration of the TTI to be used in downstream
direction (See Figure 2). direction (See Figure 2).
2 - Upstream TTI for double TTI configuration: the current TLV 2 - Upstream TTI for double TTI configuration: the current TLV
instruct the configuration of the TTI to be used in upstream instructs the configuration of the TTI to be used in upstream
direction (See Figure 2). direction (See Figure 2).
3 - Invalid. 3 - Invalid.
If the APP is set to 1 and the next or the previous sub-TLV is not an If the APP is set to 1 and the next or the previous sub-TLV is not an
OTN TTI Configuration TLV with APP code point 2, then an error must OTN TTI Configuration TLV with APP code point 2, then an error must
be generated "OAM Problem/Invalid OTN TTI Configuration/Missing be generated "OAM Problem/Invalid OTN TTI Configuration - Missing
Upstream TTI configuration". Upstream TTI configuration".
If the APP is set to 2 and the next or the previous sub-TLV is not an If the APP is set to 2 and the next or the previous sub-TLV is not an
OTN TTI Configuration TLV with APP code point 1, then an error must OTN TTI Configuration TLV with APP code point 1, then an error must
be generated "OAM Problem/Invalid OTN TTI Configuration/Missing be generated "OAM Problem/Invalid OTN TTI Configuration - Missing
Downstream TTI configuration". Downstream TTI configuration".
If the APP is set to either 1 or 2 and the unidirectional LSP is If the APP is set to either 1 or 2 and the unidirectional LSP is
signaled (no UPSTREAM_LABEL is added to the message) or the APP is signaled (no UPSTREAM_LABEL is added to the message) or the APP is
set to 3, an error must be generated "OAM Problem/Invalid OTN TTI set to 3, an error must be generated "OAM Problem/Invalid OTN TTI
Configuration/Invalid applicability code" Configuration - Invalid applicability code".
3.7. Degraded signal thresholds Sub-TLV 3.8. Degraded Signal Thresholds Sub-TLV
The Degraded signal thresholds Sub-TLV instructs the configuration of The Degraded Signal Thresholds Sub-TLV instructs the configuration of
the signal quality supervision function. This sub-TLV is applicable the signal quality supervision function. This sub-TLV is applicable
in both SONET/SDH and OTN cases. This sub-TLV can be carried in both in both SONET/SDH and OTN cases. This sub-TLV can be carried in both
the SONET/SDH OAM Configuration sub-TLV or OTN OAM Configuration sub- the SONET/SDH OAM Configuration Sub-TLV or OTN OAM Configuration Sub-
TLV, if the PerformanceMonitoring/Loss OAM Function Flag is set. TLV, if the PerformanceMonitoring/Loss OAM Function Flag is set.
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 = 4 | | Type (IANA) | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B|L| Reserved | DEG_THR | DEG_M | |B|L| Reserved | DEG_THR | DEG_M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Two flags are defined to encode the signal quality measurement. The Two flags are defined to encode the signal quality measurement. The
bit "B" encodes if distribution of errors is either Poisson (B=0) or bit "B" encodes if distribution of errors is either Poisson (B=0) or
Bursty (B=1). In case of Poisson distribution of errors two levels Bursty (B=1). In case of Poisson distribution of errors, two levels
of defects are defined and encoded with bit "L": excessive error of defects are defined and encoded with bit "L": excessive error
(L=0) and degraded signal (L=1). Since in case of Bursty (L=0) and degraded signal (L=1). Since in case of Bursty
distribution of errors only degraded signal defect is to be detected, distribution of errors, only degraded signal defect is to be
therefore, in this latter case (B=1) the "L" bit must be set. detected, therefore, in this latter case (B=1), the "L" bit must be
Otherwise error must be generated: "OAM Problem/Invalid Performance set. Otherwise, an error must be generated: "OAM Problem/Invalid
Monitoring/Loss configuration". Performance Monitoring/Loss configuration".
The field "DEG_THR" defines the threshold for the bad frames (BIP-8 The field "DEG_THR" defines the threshold for the bad frames (BIP-8
violations) in both, Poisson and bursty distributions of errors. In violations) in both Poisson and bursty distributions of errors. In
the first case (B=0) this field encodes the quotient of the threshold the first case (B=0), this field encodes the quotient of the
10e-X. The possible values for excessive error are 3,4 and 5, while threshold 10e-X. The possible values for excessive error are 3,4 and
for degraded signal defect are 6,7,8 and 9. 5, while for degraded signal defect, the values are 6,7,8 and 9.
In the second case (B=1) it encodes ratio of the bad frames in a In the second case (B=1), it encodes the ratio of the bad frames in a
1-second period and can be set between 0 and 100, interpreted as 1-second period and can be set between 0 and 100, interpreted as
ratios in percentage. ratios in percentage.
The field "DEG_M" defines monitoring time-frame in 1 second periods The field "DEG_M" defines the monitoring time-frame in 1 second
assuming bursty distribution of errors. The valid values are 2 to 10 periods assuming bursty distribution of errors. The valid values are
periods. 2 to 10 periods.
4. Error handling 4. Error handling
In addition to error values specified in [GMPLS-OAM-FWK] this In addition to error values specified in
document defines the following values for the "OAM Problem" Error [I-D.ietf-ccamp-oam-configuration-fwk] this document defines the
Code. following values for the "OAM Problem" Error Code.
o In case of SONET/SDH if Performance Measurement/Delay flag is set
in the OAM Functions Flag sub-TLV, an error must be generated "OAM
Problem/Unsupported OAM Function".
o In case of OTN if the equipment does not support delay measurement
and the Performance Measurement/Delay flag is set in the received
OAM Functions Flag sub-TLV, an error must be generated "OAM
Problem/Unsupported OAM Function".
o In case of SONET/SDH OAM when the length or format of the TTI to If in the OTN TTI Configuration Sub-TLV both the "S" and "D" bits are
be configured is not supported by the referred SONET/SDH layer, an set to 0, an error must be generated: "OAM Problem/Invalid CC/CV
error must be generated: "OAM Problem/TTI Length Mismatch". Configuration".
o If both "S" and "D" bits in OTN TTI Configuration TLV are set to If the specified length and format of the TTI carried in the SONET/
0, error must be generated: "OAM Problem/Invalid CC/CV SDH TTI Configuration Sub-TLV is not supported by the SONET/SDH
configuration" layer, an error must be generated: "OAM Problem/TTI Length Mismatch"
o If the APP is set to 1 and the next or the previous sub-TLV is not If in the OTN TTI Configuration Sub-TLV the "APP" field is set to 1
an OTN TTI Configuration TLV with APP code point 2, then an error and the next or the previous sub-TLV is not an OTN TTI Configuration
must be generated "OAM Problem/Invalid OTN TTI Configuration/ TLV with "APP" code point 2, then an error must be generated "OAM
Missing Upstream TTI configuration". Problem/Invalid OTN TTI Configuration - Missing Upstream TTI
Configuration".
o If the APP is set to 2 and the next or the previous sub-TLV is not If in the OTN TTI Configuration Sub-TLV the "APP" field is set to 2
an OTN TTI Configuration TLV with APP code point 1, then an error and the next or the previous sub-TLV is not an OTN TTI Configuration
must be generated "OAM Problem/Invalid OTN TTI Configuration/ TLV with APP code point 1, then an error must be generated "OAM
Missing Downstream TTI configuration". Problem/Invalid OTN TTI Configuration - Missing Downstream TTI
Configuration".
o If the APP is set to either 1 or 2 and the unidirectional LSP is If in the OTN TTI Configuration Sub-TLV the "APP" field is set to
signaled (no UPSTREAM_LABEL is added to the message) or the APP is either 1 or 2 and an unidirectional LSP is signaled (no
set to 3, an error must be generated "OAM Problem/Invalid OTN TTI UPSTREAM_LABEL) or the "APP" field is set to 3, an error must be
Configuration/Invalid applicability code" generated "OAM Problem/Invalid OTN TTI Configuration - Invalid
Applicability Code".
o If flag "B" in Degraded signal thresholds Sub-TLV is set to 1 and If flag "B" in Degraded Signal Thresholds Sub-TLV is set to 1 and
flag "L" in the same sub-TLV is set to 0 error must be generated flag "L" in the same sub-TLV is set to 0, an error must be generated
"OAM Problem/Invalid Performance Monitoring/Loss configuration". "OAM Problem/Invalid Performance Monitoring/Loss Configuration".
5. IANA Considerations 5. IANA Considerations
This document specifies two new sub-TLVs to be carried in the OAM This document specifies two new sub-TLVs to be carried in the OAM
Configuration TLV in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES Configuration TLV in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES
Objects in Path and Resv messages. The document assigns values 3 and Objects in Path and Resv messages. The document defines two new
4 from the "OAM Type" field of the OAM Configuration TLV. values of the "OAM Type" field of the OAM Configuration TLV. IANA is
requested to make the following assignments in the RSVP-TE OAM
Configuration Registry.
The following error values need to be assigned under "OAM Problem" RSVP-TE OAM Configuration Registry
error code: "OAM Problem/Unsupported OAM Function", "OAM Problem/TTI
Length Mismatch", "OAM Problem/Invalid CC/CV configuration", "OAM OAM Type Description
Problem/Invalid OTN TTI Configuration/Missing Upstream TTI ------------------- -----------------------------------
configuration", "OAM Problem/Invalid OTN TTI Configuration/Missing 3 SONET/SDH OAM
Downstream TTI configuration", "OAM Problem/Invalid OTN TTI 4 OTN Digital Hierarchy OAM
Configuration/Invalid applicability code", "OAM Problem/Invalid
Performance Monitoring/Loss configuration". Sub-TLV Type Description
------------------- -----------------------------------
34 SONET/SDH OAM Configuration Sub-TLV
35 OTN OAM Configuration Sub-TLV
IANA is requested to maintain the SONET/SDH and OTN TLV Type space in
the "RSVP-TE OAM Configuration Registry" for the sub-TLV types
carried in the SONET/SDH and OTN OAM Configuration Sub-TLVs. This
document defines the following types.
SONET/SDH and OTN TLV Type Description
-------------------------- --------------------------------
0 Reserved
1 SONET/SDH TTI Configuration Sub-TLV
2 OTN TTI Configuration Sub-TLV
3 Degraded Signal Thresholds Sub-TLV
IANA is requested to assigne the following error values under the
"OAM Problem" error code: "TTI Length Mismatch", "Invalid CC/CV
Configuration", "Invalid OTN TTI Configuration - Missing Upstream TTI
Configuration", "Invalid OTN TTI Configuration - Missing Downstream
TTI Configuration", "Invalid OTN TTI Configuration - Invalid
Applicability Code", "Invalid Performance Monitoring/Loss
Configuration".
6. Security Considerations 6. Security Considerations
Security aspects are addressed in the OAM configuration framework Security aspects are addressed in the OAM configuration framework
document [GMPLS-OAM-FWK] document [I-D.ietf-ccamp-oam-configuration-fwk]. This document does
not introduce any additional security issues to those discussed in
[I-D.ietf-ccamp-oam-configuration-fwk] and the SONET/SDH and OTN
technology-specific RFCs.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Francesco Fondelli for his useful The authors would like to thank Francesco Fondelli for his useful
comments. comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[GMPLS-OAM-FWK] [I-D.ietf-ccamp-oam-configuration-fwk]
Takacs, A., Fedyk, D., and H. Jia, "OAM Configuration Takacs, A., Fedyk, D., and H. Jia, "GMPLS RSVP-TE
Framework and Requirements for GMPLS RSVP-TE", extensions for OAM Configuration", draft-ietf-ccamp-oam-
draft-ietf-ccamp-oam-configuration-fwk-01 (work in configuration-fwk-10 (work in progress), June 2013.
progress), March 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References 8.2. Informative References
[G.707] International Telecommunications Union, "Network node [G.707] International Telecommunications Union, "Network node
interface for the synchronous digital hierarchy (SDH)", interface for the synchronous digital hierarchy (SDH)",
ITU-T Recommendation G.707, January 2007. ITU-T Recommendation G.707, 2007.
[G.709] International Telecommunications Union, "Interfaces for [G.709] International Telecommunications Union, "Interfaces for
the Optical Transport Network (OTN)", ITU-T the Optical Transport Network (OTN)", ITU-T Recommendation
Recommendation G.709, March 2003. G.709, 2012.
[G.709v3] International Telecommunications Union, "Interfaces for
the Optical Transport Network (OTN)", ITU-T
Recommendation G.709, December 2009.
[G.798] International Telecommunications Union, "Characteristics [G.798] International Telecommunications Union, "Characteristics
of optical transport network hierarchy equipment of optical transport network hierarchy equipment
functional blocks", ITU-T Recommendation G.798, functional blocks ", ITU-T Recommendation G.798, 2006.
December 2006.
[G.806] International Telecommunications Union, "Characteristics [G.806] International Telecommunications Union, "Characteristics
of transport equipment - Description methodology and of transport equipment - Description methodology and
generic functionality", ITU-T Recommendation G.806, generic functionality", ITU-T Recommendation G.806, 2009.
January 2009.
[OTNv3_SIG]
Zhang, F., Zhang, G., Belotti, S., Ceccarelli, D., and K.
Pithewan, "Operating Virtual Concatenation (VCAT) and the
Link Capacity Adjustment Scheme (LCAS) with Generalized
Multi-Protocol Label Switching (GMPLS)",
draft-ietf-ccamp-gmpls-signaling-g709v3-01 (work in
progress), October 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for G.709 Optical Switching (GMPLS) Signaling Extensions for G.709 Optical
Transport Networks Control", RFC 4328, January 2006. Transport Networks Control", RFC 4328, January 2006.
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC 4606, August 2006. Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
[RFC6344] Bernstein, G., Caviglia, D., Rabbat, R., and H. Helvoort, [RFC6344] Bernstein, G., Caviglia, D., Rabbat, R., and H. van
"Operating Virtual Concatenation (VCAT) and the Link Helvoort, "Operating Virtual Concatenation (VCAT) and the
Capacity Adjustment Scheme (LCAS) with Generalized Multi- Link Capacity Adjustment Scheme (LCAS) with Generalized
Protocol Label Switching (GMPLS)", RFC 6344, August 2011. Multi-Protocol Label Switching (GMPLS)", RFC 6344, August
2011.
Authors' Addresses Authors' Addresses
Andras Kern Andras Kern
Ericsson Ericsson
Laborc u. 1. Laborc u. 1.
Budapest, 1037 Budapest 1037
Hungary Hungary
Email: andras.kern@ericsson.com Email: andras.kern@ericsson.com
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. 98 change blocks. 
347 lines changed or deleted 347 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/