idnits 2.17.1 draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 10, 2013) is 3814 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-13) exists of draft-ietf-ccamp-oam-configuration-fwk-10 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Kern 3 Internet-Draft A. Takacs 4 Intended status: Standards Track Ericsson 5 Expires: May 14, 2014 November 10, 2013 7 GMPLS RSVP-TE Extensions for SONET/SDH and OTN OAM Configuration 8 draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-06 10 Abstract 12 GMPLS has been extended to support connection establishment in both 13 SONET/SDH and OTN networks. However support for the configuration of 14 the OAM functions is not specified. Both SONET/SDH and OTN implement 15 OAM functions to monitor the transported signals. This document 16 defines extensions to RSVP-TE for SONET/SDH and OTN OAM configuration 17 based on the OAM Configuration Framework defined in a separate 18 document. This document supports, but does not modify, ITU-T OAM 19 mechanisms. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 14, 2014. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Overview of SONET/SDH and OTN OAM related functions . . . . . 3 63 2.1. Continuity supervision . . . . . . . . . . . . . . . . . 3 64 2.2. Connectivity supervision . . . . . . . . . . . . . . . . 3 65 2.2.1. SONET/SDH . . . . . . . . . . . . . . . . . . . . . . 4 66 2.2.2. OTN . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.3. Signal quality supervision . . . . . . . . . . . . . . . 4 68 2.3.1. SONET/SDH . . . . . . . . . . . . . . . . . . . . . . 4 69 2.3.2. OTN . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.4. Delay measurement . . . . . . . . . . . . . . . . . . . . 5 71 3. RSVP-TE signaling extensions . . . . . . . . . . . . . . . . 5 72 3.1. Operation overview . . . . . . . . . . . . . . . . . . . 5 73 3.1.1. Continuity Check supervision . . . . . . . . . . . . 6 74 3.1.2. Connectivity Monitoring supervision . . . . . . . . . 6 75 3.1.2.1. SDH/SONET . . . . . . . . . . . . . . . . . . . . 6 76 3.1.2.2. OTN . . . . . . . . . . . . . . . . . . . . . . . 6 77 3.1.3. Signal quality supervision . . . . . . . . . . . . . 7 78 3.2. Signaling support of Virtual Concatenation Groups (VCG) . 8 79 3.3. OAM types and functions . . . . . . . . . . . . . . . . . 8 80 3.4. SONET/SDH OAM Configuration Sub-TLV . . . . . . . . . . . 9 81 3.5. OTN OAM Configuration Sub-TLV . . . . . . . . . . . . . . 9 82 3.6. SDH TTI Configuration Sub-TLV . . . . . . . . . . . . . . 9 83 3.7. OTN TTI Configuration Sub-TLV . . . . . . . . . . . . . . 10 84 3.8. Degraded Signal Thresholds Sub-TLV . . . . . . . . . . . 12 85 4. Error handling . . . . . . . . . . . . . . . . . . . . . . . 13 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 88 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 91 8.2. Informative References . . . . . . . . . . . . . . . . . 15 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 95 1. Introduction 97 Both SONET/SDH and OTN implement OAM functions to monitor the 98 transported signals. Supervision functions include continuity, 99 connectivity, signal quality, alignment and payload supervision. The 100 ITU-T G.806 [G.806] recommendation defines the generic framework of 101 the supervision functions, which are then further specified for SONET 102 /SDH and OTN in technology specific documents. 104 GMPLS has been extended to support connection establishment in SONET/ 105 SDH [RFC4606], and in OTN [RFC4328] [RFC6344] networks. These 106 documents however do not support the configuration of the respective 107 OAM supervision functions. 109 [I-D.ietf-ccamp-oam-configuration-fwk] defines a technology-agnostic 110 framework for GMPLS to support the establishment and configuration of 111 the pro-active OAM functions of signaled connections. The properties 112 of the OAM functions are exchanged during connection establishment 113 and may be modified during the life of the connection. The 114 technology specific parameters to be exchanged are to be described in 115 accompanying documents. This document defines the extensions for 116 SONET/SDH and OTN OAM configuration for end-to-end monitoring. 118 2. Overview of SONET/SDH and OTN OAM related functions 120 SONET/SDH [G.707] and OTN [G.709] provide a variety of supervision 121 functions. Among these functions we consider continuity, 122 connectivity and signal quality supervision functions, as these are 123 the candidates for GMPLS based configuration. We also consider delay 124 measurement functionality for OTN. The reader should refer to the 125 ITU-T documents for additional information. Familiarity with GMPLS, 126 SONET/SDH and OTN terminology is assumed. 128 2.1. Continuity supervision 130 Continuity supervision provides methods for monitoring the health of 131 a connection (trail). 133 2.2. Connectivity supervision 135 The connectivity supervision function provides a method to detect 136 misconnections. The detection procedure is based on a Trace Trail 137 Identifier (TTI) known by both endpoints. The TTI is included by the 138 source node as an overhead signal for each connection. The receiver 139 node then compares the received TTI with the expected value and 140 determines if a mis-connection occurred. 142 2.2.1. SONET/SDH 144 In case of SONET/SDH, connectivity supervision is implemented in the 145 Regeneration Section (RS) and in the lower and higher order path 146 layers (LOVC and HOVC). In all layers the TTI encodes only the 147 Access Point Identifier (API) of the source node. In the various 148 layers, the lengths of these TTIs are different. In RS, the TTI 149 (encoded in J0 byte) is either 1 or 16 bytes long. In higher order 150 paths the TTI (encoded in J1), is either 16 or 64 bytes long. In 151 lower order paths, the TTI is transmitted in the J2 byte and is 16 152 bytes long. 154 2.2.2. OTN 156 In case of OTN, connectivity supervision is supported by the OTUk and 157 ODUk digital hierarchy layers. In both layers, the length of the TTI 158 is 64 bytes, but only the first 32 bytes are considered for 159 connectivity supervision. This first part is further divided into a 160 Source Access Point Identifier (SAPI) and a Destination Access Point 161 Identifier (DAPI). Connectivity supervision may consider either the 162 SAPI or DAPI only or both. The structure of the SAPI and DAPI is 163 specified in [G.709]. 165 2.3. Signal quality supervision 167 The quality of the transmitted signal is monitored as a ratio of bad 168 frames. If the number of such frames reaches a threshold, a defect 169 state is declared. To detect the correctness of the frames, an Error 170 Detection Code (EDC), such as Bit Interleaved Parity (BIP), is used. 171 The distribution of the errors is assumed to follow either Poisson or 172 a bursty distribution. For Poisson distribution, an EDC violation 173 ratio is defined as the threshold; while for the bursty model, the 174 threshold is defined as a number of consecutive 1-second time 175 intervals in which the EDC violation exceeds a predefined ratio. In 176 case of Poisson error distribution, two defect state levels are 177 defined: the Excessive Error and Degraded Signal defect. In the case 178 of the bursty model, only the Degraded Signal defect level is 179 considered. 181 2.3.1. SONET/SDH 183 SONET/SDH supports both Excessive Error and Degraded Signal defect 184 levels and supports both Poisson and bursty error distribution 185 models. These signal quality parameters are configured for the 186 Multiplexing Section (MS) and the LOVC and HOVC path layers. 188 2.3.2. OTN 189 For OTN, in the digital transport layers (OTUk and ODUk), only the 190 bursty error distribution model with the Degraded Signal defect level 191 is supported. Two parameters are defined: Ratio of the bad frames in 192 a one second interval (0% to 100% or 0 to number of frames per 193 1-second interval) and Number of consecutive intervals (between 2 and 194 10). Signal quality supervision in the optical transport layers is 195 not specified by [G.798], it is indicated to be for further study. 197 2.4. Delay measurement 199 [G.709] introduced a tool for measuring round-trip delay of a 200 bidirectional ODU path or tandem connection. For implementing delay 201 measurement, a one-bit delay measurement (DM) signal is defined in 202 the ODUk header. That signal bit is a constant value (either 0 or 203 1). One endpoint initiates a delay measurement by inverting the bit 204 emitted in the DM signal. The remote endpoint loops back the DM 205 signal; therefore, the delay measurement initiating node will receive 206 the inverted signal from the remote endpoint. This way the 207 initiating endpoint will determine the round trip delay. 209 3. RSVP-TE signaling extensions 211 3.1. Operation overview 213 RFC 4328, RFC 4606 and RFC6344 defined the GMPLS RSVP-TE extensions 214 necessary to manage SONET/SDH and OTN optical and digital hierarchy 215 connections. The monitoring functions associated to these 216 connections MAY be configured when configuring the connections. 218 The LSP Attribute Flag "OAM MEP entities desired" 219 [I-D.ietf-ccamp-oam-configuration-fwk] MUST be used to signal that 220 the monitoring functions at the endpoints MUST be established. The 221 "OAM MIP entities desired" flag MUST be set to 0 and MUST be ignored. 223 To configure OAM parameters, the OAM Configuration TLV MAY be 224 included in the LSP_ATTRIBUTES object. The TLV identifies which OAM 225 technology ("OAM Type" field) to be used as well as which OAM 226 functions are to be enabled (OAM Function Flags Sub-TLV). For SONET/ 227 SDH and OTN, the "Continuity Check" and "Connectivity Verification" 228 flags control the Continuity and Connectivity supervision functions, 229 while the "Performance Monitoring/Loss" flag enables the Signal 230 Quality supervision function. 232 The recent revision of OTN [G.709] introduced delay measurement 233 capability for paths. A node MAY enable delay measurement by setting 234 the "Performance Monitoring/Delay" flag. By setting that flag, the 235 node also indicates that it will initiate the delay measurement; 236 therefore, the remote endpoint node SHOULD NOT initiate delay 237 measurement over the configured connection. Equipment designed to 238 earlier versions of G709 MUST clear the "Performance Monitoring/Loss" 239 flag and upon receiving an OAM configuration message with 240 "Performance Monitoring/Delay" flag set MUST generate "OAM Problem/ 241 Unsupported OAM Function" error. The "Performance Monitoring/Delay" 242 flag MUST be cleared for SONET/SDH as it is not supported by SONET/ 243 SDH. 245 For additional details, the appropriate technology specific sub-TLV 246 MAY be carried in the OAM Configuration TLV. 248 3.1.1. Continuity Check supervision 250 In case of both SONET/SDN and OTN technologies, setting up the 251 continuity supervision function for a connection does not need 252 further configuration besides enabling it. Therefore, by setting the 253 "Connectivity Monitoring" Flag of OAM Function implicitly enables the 254 continuity supervision function as well. 256 3.1.2. Connectivity Monitoring supervision 258 3.1.2.1. SDH/SONET 260 [G.707] defines three TTI overhead bytes (signals) for connectivity 261 supervision: the J0 byte in RS layer, the J1 byte in the HOVC layer 262 and the J2 byte in the LOVC layer. The source node transmits the TTI 263 and the destination node matches it with the expected one. When the 264 destination detects mismatch, a defect state will be declared. 266 Since these bytes encode a TTI identifier defined for the source 267 node, different stream will be emitted in the upstream and downstream 268 directions for bidirectional connections. During the configuration 269 the downstream (destination) node has to be configured with the TTI 270 value to be expected in the downstream direction and the TTI value to 271 be emitted in the upstream direction. Therefore, the SONET/SDH OAM 272 Configuration TLV carries two Connectivity Supervision TLVs. 274 3.1.2.2. OTN 276 [G.709] defines a 64 byte long TTI format, where the first 32 bytes 277 have a generic structure: a zero byte, a 15 bytes long SAPI, a second 278 zero byte and finally the 15 bytes long DAPI format. 280 For a unidirectional connection, a single Connection Supervision TLV 281 encodes elements of the TTI to be emitted. This TLV also specifies 282 which parts of the TTI are compared to the expected values (only 283 SAPI, only DAPI, both SAPI and DAPI). 285 In case of a bidirectional connection an endpoint can use a common 286 API value for SAPI (for transmitted signal) and DAPI (for received 287 signal). (See Figure 1.) The TTI values used in downstream and 288 upstream directions are derived from the two API values: the 289 downstream TTI will have the form of [0, API_a, 0, API_z] while the 290 upstream TTI will use the form of [0, API_z, 0 API_a]. 292 Ingress Node Egress Node 293 ( API_a ) TTI_upstream = [0, API_z, 0, API_a ] ( API_z ) 294 | Rx port | -- < -- < -- < -- < -- < -- < -- < -- < -- | Tx Port | 295 | Tx port | -- > -- > -- > -- > -- > -- > -- > -- > -- | Rx Port | 296 TTI_downstream = [0, API_a, 0, API_z ] 298 Figure 1: TTI construction when a single API identifies the receiver 299 and transmitter interfaces 301 Then, a single Connectivity Supervision TLV is defined. The SAPI 302 field carries the API of the ingress node (API_a) that initiates the 303 signaling, while the DAPI carries the API of the egress node (API_z). 305 On the other hand, it is possible that the endpoints use different 306 values as SAPI and DAPI to identify the transmitter and receiver 307 ports of a bidirectional connection (See Figure 2). In this case the 308 TTIs to be used in the two directions are independent, thus, they 309 must be explicitly configured. Therefore, two Connectivity 310 Supervision TLVs are added to the OTN OAM Configuration TLV. Each 311 TLV encodes whether it defines the downstream or the upstream TTI. 313 Ingress Node Egress Node 314 ( API_a1 ) TTI_upstream = [0, API_z1, 0, API_a1 ] ( API_z1 ) 315 | Rx port | -- < -- < -- < -- < -- < -- < -- < -- < -- | Tx Port | 316 | Tx port | -- > -- > -- > -- > -- > -- > -- > -- > -- | Rx Port | 317 ( API_a2 ) TTI_downstream = [0, API_a2, 0, API_z2 ] ( API_z2 ) 319 Figure 2: TTI construction when dedicated APIs identify the receiver 320 and transmitter interfaces 322 3.1.3. Signal quality supervision 324 Signal quality supervision function is implemented in the MS, HOVC, 325 LOVC layers of SONET/SDH. All three layers support exceeded error 326 level with Poisson error distribution model and degraded signal 327 defect level with both of the Poisson and bursty error distribution 328 models. Dedicated Signal quality supervision TLVs encode each level, 329 therefore when the "Performance Monitoring/Loss" flag is set; several 330 such TLVs MAY be added to the SONET/SDH OAM Configuration TLV. If a 331 configuration TLV for a particular level is missing, the default 332 parameters for that level SHOULD be applied. 334 OTN supports only Degraded Signal defect with bursty error model in 335 OTUk and ODUk layers. Thus, the only parameters to be encoded are: 336 the threshold for bad frames in a 1-second interval and the number of 337 consecutive 1-second intervals with excessive bad frames. 338 Furthermore, as only one level is allowed, a single Signal quality 339 supervision TLV MAY be added to the OTN OAM Configuration TLV. 341 3.2. Signaling support of Virtual Concatenation Groups (VCG) 343 A capability of both SONET/SDH and OTN is the support of virtual 344 concatenation. This inverse multiplexing method uses multiplicity of 345 parallel individual signals. The supervision function parameters of 346 these basic signals can be different. 348 [RFC6344] describes GMPLS signaling capabilities to support virtual 349 concatenation. A Virtual Concatenated Group (VCG) is constructed 350 from several individual data plane signals. The co-routed signals of 351 a VCG may be provisioned together using a single RSVP-TE session (co- 352 signaled). As different OAM configuration may be applied to each of 353 these individual signals, the OAM configuration extension is applied 354 as follows. 356 We assume that the same OAM type and the same set of OAM functions 357 apply to each individual signal of the VCG. A single OAM 358 Configuration TLV MUST be carried in the LSP_ATTRIBUTES Object, while 359 multiple instances of technology specific OAM configuration sub-TLVs 360 MAY be added: one instance per individual signal. The order of these 361 TLVs references the logical order of the individual signals (as they 362 are listed in the Label Object). 364 [RFC6344] allows extension/pruning of a VCG. To achieve it, the 365 traffic descriptor, which encodes how the VCG is structured, in the 366 RSVP-TE session is updated. If the VCG is updated, the contents of 367 the OAM Configuration TLV MUST be updated accordingly. 369 3.3. OAM types and functions 371 This document defines two new code points for the "OAM Type" field of 372 the OAM Configuration TLV, defined in 373 [I-D.ietf-ccamp-oam-configuration-fwk]: SONET/SDH OAM and OTN Digital 374 Hierarchy OAM. 376 The "OAM Function Flags Sub-TLV" is defined in 377 [I-D.ietf-ccamp-oam-configuration-fwk]. SONET/SDH and OTN 378 supervision functions are defined in this document for the following 379 flags: "Continuity Check", "Connectivity Verification", "Performance 380 Monitoring/Loss" and "Performance Monitoring/Delay". 382 3.4. SONET/SDH OAM Configuration Sub-TLV 384 SONET/SDH OAM Configuration Sub-TLV is defined to encode the 385 parameters of continuity, connectivity and signal quality supervision 386 functions for SONET/SDH networks. 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Type (34) (IANA) | Length | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | | 394 ~ sub TLVs ~ 395 | | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 Type: indicates a new type: the SONET/SDH OAM Configuration TLV (IANA 399 to define). 401 Length: indicates the total length including sub-TLVs 403 3.5. OTN OAM Configuration Sub-TLV 405 OTN OAM Configuration TLV is defined to encode the parameters of 406 continuity, connectivity and signal quality supervision functions for 407 OTN. 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Type (35) (IANA) | Length | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | | 415 ~ sub TLVs ~ 416 | | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 Type: indicates a new type: the OTN OAM Configuration TLV (IANA to 420 define). 422 Length: indicates the total length including sub-TLVs 424 3.6. SDH TTI Configuration Sub-TLV 425 This sub-TLV is carried in the SONET/SDH OAM Configuration Sub-TLV, 426 if the Connectivity Verification OAM Function Flag is set. In each 427 supporting layer, the TTI identifies the source interface (SAPI); 428 however, the length of this identifier varies layer-by-layer (see 429 Section 2.2.1). Therefore, a generic TLV is defined supporting 430 various TTI lengths. 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Type (IANA) | Length | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 |A|U| Reserved | TTI | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | | 440 ~ TTI cont ~ 441 | | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 Flag "A", when set enables the AIS insertion when detecting a TTI 445 mismatch. 447 Flag "U" encodes if the TTI refers to the downstream node's source 448 TTI (U=0) or the upstream node's TTI (U=1) (expected TTI). 450 The TTI field carries the TTI to be transmitted by the source node 451 and to be expected by the sink. The TLV is padded to 4 bytes. 453 If the specified length and format of the TTI carried in this TLV is 454 not supported by the referenced SONET/SDH layer, an error must be 455 generated: "OAM Problem/TTI Length Mismatch". 457 3.7. OTN TTI Configuration Sub-TLV 459 This sub-TLV is carried in the OTN OAM Configuration Sub-TLV, if the 460 Connectivity Verification OAM Function Flag is set. 462 0 1 2 3 463 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 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Type (IANA) | Length = 32 | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 |A|S|D|APP| Reserved | SAPI | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | SAPI cont | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | SAPI cont | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | SAPI cont | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | SAPI | DAPI | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | DAPI cont | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | DAPI cont | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | DAPI cont | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 Three control flags are defined. Flag "A" indicates that AIS 485 insertion when detecting a TTI mismatch (failing the connectivity 486 verification) is required (A=1) or not (A=0). The next two flags 487 define which parts of the received TTI are compared to the expected 488 one. If flag "S" is set, the TTI bytes 1 to 15 are matched to the 489 expected SAPI value. If the flag "D" is set, the TTI bytes 17 to 31 490 are matched to the expected DAPI value. If both "S" and "D" are set, 491 both parts of TTI are compared to SAPI and DAPI values. Setting both 492 "S" and "D" bits to 0 is invalid, and if encountered, an error must 493 be generated: "OAM Problem/Invalid CC/CV configuration". 495 The next two bits "APP" encode the applicability of the TTI 496 configuration and the following code points are defined: 498 0 - Single TTI configuration: the TTI configuration is done 499 according only to this TLV and no further TTI configuration TLVs 500 are expected. This code point is used for unidirectional 501 connections and for bidirectional connections with common APIs 502 (See Figure 1) 504 1 - Downstream TTI for double TTI configuration: the current TLV 505 instructs the configuration of the TTI to be used in downstream 506 direction (See Figure 2). 508 2 - Upstream TTI for double TTI configuration: the current TLV 509 instructs the configuration of the TTI to be used in upstream 510 direction (See Figure 2). 512 3 - Invalid. 514 If the APP is set to 1 and the next or the previous sub-TLV is not an 515 OTN TTI Configuration TLV with APP code point 2, then an error must 516 be generated "OAM Problem/Invalid OTN TTI Configuration - Missing 517 Upstream TTI configuration". 519 If the APP is set to 2 and the next or the previous sub-TLV is not an 520 OTN TTI Configuration TLV with APP code point 1, then an error must 521 be generated "OAM Problem/Invalid OTN TTI Configuration - Missing 522 Downstream TTI configuration". 524 If the APP is set to either 1 or 2 and the unidirectional LSP is 525 signaled (no UPSTREAM_LABEL is added to the message) or the APP is 526 set to 3, an error must be generated "OAM Problem/Invalid OTN TTI 527 Configuration - Invalid applicability code". 529 3.8. Degraded Signal Thresholds Sub-TLV 531 The Degraded Signal Thresholds Sub-TLV instructs the configuration of 532 the signal quality supervision function. This sub-TLV is applicable 533 in both SONET/SDH and OTN cases. This sub-TLV can be carried in both 534 the SONET/SDH OAM Configuration Sub-TLV or OTN OAM Configuration Sub- 535 TLV, if the PerformanceMonitoring/Loss OAM Function Flag is set. 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Type (IANA) | Length = 4 | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 |B|L| Reserved | DEG_THR | DEG_M | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 Two flags are defined to encode the signal quality measurement. The 546 bit "B" encodes if distribution of errors is either Poisson (B=0) or 547 Bursty (B=1). In case of Poisson distribution of errors, two levels 548 of defects are defined and encoded with bit "L": excessive error 549 (L=0) and degraded signal (L=1). Since in case of Bursty 550 distribution of errors, only degraded signal defect is to be 551 detected, therefore, in this latter case (B=1), the "L" bit must be 552 set. Otherwise, an error must be generated: "OAM Problem/Invalid 553 Performance Monitoring/Loss configuration". 555 The field "DEG_THR" defines the threshold for the bad frames (BIP-8 556 violations) in both Poisson and bursty distributions of errors. In 557 the first case (B=0), this field encodes the quotient of the 558 threshold 10e-X. The possible values for excessive error are 3,4 and 559 5, while for degraded signal defect, the values are 6,7,8 and 9. 561 In the second case (B=1), it encodes the ratio of the bad frames in a 562 1-second period and can be set between 0 and 100, interpreted as 563 ratios in percentage. 565 The field "DEG_M" defines the monitoring time-frame in 1 second 566 periods assuming bursty distribution of errors. The valid values are 567 2 to 10 periods. 569 4. Error handling 571 In addition to error values specified in 572 [I-D.ietf-ccamp-oam-configuration-fwk] this document defines the 573 following values for the "OAM Problem" Error Code. 575 If in the OTN TTI Configuration Sub-TLV both the "S" and "D" bits are 576 set to 0, an error must be generated: "OAM Problem/Invalid CC/CV 577 Configuration". 579 If the specified length and format of the TTI carried in the SONET/ 580 SDH TTI Configuration Sub-TLV is not supported by the SONET/SDH 581 layer, an error must be generated: "OAM Problem/TTI Length Mismatch" 583 If in the OTN TTI Configuration Sub-TLV the "APP" field is set to 1 584 and the next or the previous sub-TLV is not an OTN TTI Configuration 585 TLV with "APP" code point 2, then an error must be generated "OAM 586 Problem/Invalid OTN TTI Configuration - Missing Upstream TTI 587 Configuration". 589 If in the OTN TTI Configuration Sub-TLV the "APP" field is set to 2 590 and the next or the previous sub-TLV is not an OTN TTI Configuration 591 TLV with APP code point 1, then an error must be generated "OAM 592 Problem/Invalid OTN TTI Configuration - Missing Downstream TTI 593 Configuration". 595 If in the OTN TTI Configuration Sub-TLV the "APP" field is set to 596 either 1 or 2 and an unidirectional LSP is signaled (no 597 UPSTREAM_LABEL) or the "APP" field is set to 3, an error must be 598 generated "OAM Problem/Invalid OTN TTI Configuration - Invalid 599 Applicability Code". 601 If flag "B" in Degraded Signal Thresholds Sub-TLV is set to 1 and 602 flag "L" in the same sub-TLV is set to 0, an error must be generated 603 "OAM Problem/Invalid Performance Monitoring/Loss Configuration". 605 5. IANA Considerations 607 This document specifies two new sub-TLVs to be carried in the OAM 608 Configuration TLV in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES 609 Objects in Path and Resv messages. The document defines two new 610 values of the "OAM Type" field of the OAM Configuration TLV. IANA is 611 requested to make the following assignments in the RSVP-TE OAM 612 Configuration Registry. 614 RSVP-TE OAM Configuration Registry 616 OAM Type Description 617 ------------------- ----------------------------------- 618 3 SONET/SDH OAM 619 4 OTN Digital Hierarchy OAM 621 Sub-TLV Type Description 622 ------------------- ----------------------------------- 623 34 SONET/SDH OAM Configuration Sub-TLV 624 35 OTN OAM Configuration Sub-TLV 626 IANA is requested to maintain the SONET/SDH and OTN TLV Type space in 627 the "RSVP-TE OAM Configuration Registry" for the sub-TLV types 628 carried in the SONET/SDH and OTN OAM Configuration Sub-TLVs. This 629 document defines the following types. 631 SONET/SDH and OTN TLV Type Description 632 -------------------------- -------------------------------- 633 0 Reserved 634 1 SONET/SDH TTI Configuration Sub-TLV 635 2 OTN TTI Configuration Sub-TLV 636 3 Degraded Signal Thresholds Sub-TLV 638 IANA is requested to assigne the following error values under the 639 "OAM Problem" error code: "TTI Length Mismatch", "Invalid CC/CV 640 Configuration", "Invalid OTN TTI Configuration - Missing Upstream TTI 641 Configuration", "Invalid OTN TTI Configuration - Missing Downstream 642 TTI Configuration", "Invalid OTN TTI Configuration - Invalid 643 Applicability Code", "Invalid Performance Monitoring/Loss 644 Configuration". 646 6. Security Considerations 648 Security aspects are addressed in the OAM configuration framework 649 document [I-D.ietf-ccamp-oam-configuration-fwk]. This document does 650 not introduce any additional security issues to those discussed in 651 [I-D.ietf-ccamp-oam-configuration-fwk] and the SONET/SDH and OTN 652 technology-specific RFCs. 654 7. Acknowledgements 655 The authors would like to thank Francesco Fondelli for his useful 656 comments. 658 8. References 660 8.1. Normative References 662 [I-D.ietf-ccamp-oam-configuration-fwk] 663 Takacs, A., Fedyk, D., and H. Jia, "GMPLS RSVP-TE 664 extensions for OAM Configuration", draft-ietf-ccamp-oam- 665 configuration-fwk-10 (work in progress), June 2013. 667 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 668 Requirement Levels", BCP 14, RFC 2119, March 1997. 670 8.2. Informative References 672 [G.707] International Telecommunications Union, "Network node 673 interface for the synchronous digital hierarchy (SDH)", 674 ITU-T Recommendation G.707, 2007. 676 [G.709] International Telecommunications Union, "Interfaces for 677 the Optical Transport Network (OTN)", ITU-T Recommendation 678 G.709, 2012. 680 [G.798] International Telecommunications Union, "Characteristics 681 of optical transport network hierarchy equipment 682 functional blocks ", ITU-T Recommendation G.798, 2006. 684 [G.806] International Telecommunications Union, "Characteristics 685 of transport equipment - Description methodology and 686 generic functionality", ITU-T Recommendation G.806, 2009. 688 [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label 689 Switching (GMPLS) Signaling Extensions for G.709 Optical 690 Transport Networks Control", RFC 4328, January 2006. 692 [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- 693 Protocol Label Switching (GMPLS) Extensions for 694 Synchronous Optical Network (SONET) and Synchronous 695 Digital Hierarchy (SDH) Control", RFC 4606, August 2006. 697 [RFC6344] Bernstein, G., Caviglia, D., Rabbat, R., and H. van 698 Helvoort, "Operating Virtual Concatenation (VCAT) and the 699 Link Capacity Adjustment Scheme (LCAS) with Generalized 700 Multi-Protocol Label Switching (GMPLS)", RFC 6344, August 701 2011. 703 Authors' Addresses 705 Andras Kern 706 Ericsson 707 Laborc u. 1. 708 Budapest 1037 709 Hungary 711 Email: andras.kern@ericsson.com 713 Attila Takacs 714 Ericsson 715 Laborc u. 1. 716 Budapest 1037 717 Hungary 719 Email: attila.takacs@ericsson.com