idnits 2.17.1 draft-rao-ccamp-mlnmrn-otn-ospfte-ext-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 106: '...dentification is OPTIONAL and used onl...' RFC 2119 keyword, line 188: '...r upper SC and Encoding type MUST have...' RFC 2119 keyword, line 233: '...al i.e. OTN or SONET/SDH, MUST include...' RFC 2119 keyword, line 236: '...ion, the path computing node MUST look...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 17, 2013) is 3844 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) == Unused Reference: 'RFC5212' is defined on line 334, but no explicit reference was found in the text == Unused Reference: 'RFC6001' is defined on line 338, but no explicit reference was found in the text == Unused Reference: 'RFC4606' is defined on line 343, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5212 -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-OTN-OSPF' Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Khuzema Pithewan 3 Intended Status: Standard Track Rajan Rao 4 Infinera 5 Expires: April 20, 2014 October 17, 2013 7 OSPF-TE extensions for MLNMRN based on OTN 8 draft-rao-ccamp-mlnmrn-otn-ospfte-ext-03.txt 10 Abstract 12 This document specifies OSPF extensions for multi-layer/multi-region 13 where one of the regions is multi-layer e.g. OTN, SONET/SDH. 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright and License Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2 Layer Identification . . . . . . . . . . . . . . . . . . . . . . 3 55 3 OTN Layer ID . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4 SONET/SDH Layer Identification . . . . . . . . . . . . . . . . . 6 57 5 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 6 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 6.1. Ethernet and OTN . . . . . . . . . . . . . . . . . . . . . 7 60 6.2. OTN and FlexGrid . . . . . . . . . . . . . . . . . . . . . 7 61 6.3. OTN and SONET/SDH . . . . . . . . . . . . . . . . . . . . . 8 62 6.4. OTN and OTN . . . . . . . . . . . . . . . . . . . . . . . . 8 63 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 64 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 65 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 68 1 Introduction 70 In order to do end-to-end path computation, where a path may involve 71 more than one region and part of single routing domain, TE Links 72 connecting the two regions need to have bandwidth capacity advertised 73 for the switch that connects the two regions. This document specifies 74 the OSPF extensions that are required if any of the region is a 75 multi-layer network. The specification is based on the requirement as 76 specified in RFC 5212. As per the said RFC, ISCD characterizes the 77 information associated to one or more network layers. Same RFC also 78 says that the information about the adjustment capabilities of the 79 nodes in the network allow the path computation process to select an 80 end-to-end multi-layer or multi- region path that includes links with 81 different switching capabilities joined by LSRs that can adapt (i.e., 82 adjust) the signal between the links. By inference, information about 83 the adjustment capabilities should be able to identify a layer in 84 ISCD, if ISCD specifies more than one layer. 86 RFC6001 specifies how to advertise adjustment capabilities between 87 two switching regions. IACD definition has provision to extend it for 88 a specific technology through Adjustment Capability Specific 89 information (ACSI) field, if required. ACSI field can be used to 90 identify a layer in the multi-layer ISCD. 92 While OTN multi-layer technology is a primary driver for this 93 extension, the extensions in this document does cover specifications 94 for multi-layer technologies in general. To make sure the extensions 95 are extensible to other multi-layer technologies as well, this 96 document covers SDH/SONET as well. 98 2 Layer Identification 100 Multi-region path computation requires to identify a layer in the 101 multi-layer region. This mandates layer identification along with 102 identification of technology in the region. The technology 103 identification is done via Switching capability and Encoding type. 105 IACD needs to be extended to be able to carry layer identification. 106 the layer Identification is OPTIONAL and used only when interface 107 supports layer multiplexing and hence creating a need to identify a 108 layer. A new Layer ID Sub-TLV has been defined to carry layer 109 identification. 111 0 1 2 3 112 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 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Type |R| Reserved | Length | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | ... | 117 | Variable size field to identify layer | 118 | ... | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 Type : Type field is used to identify a particular structure of 122 variable size field, which is specific to the particular Switching 123 Capability and Encoding type combination 125 R : This bit is used to make sense whether the Layer ID is for Lower 126 region or upper region. 1 means upper region and 0 means lower. 128 IACD can have at-most 2 Layer ID TLVs, if both the regions are multi- 129 layer. 131 Next two sections specifies Layer ID for two multi-layer technologies 132 namely, OTN and SONET/SDH 134 3 OTN Layer ID 136 RFC6001 defines IACD sub-TLV as follows. Please refer to the RFC for 137 definition of individual fields of the sub-TLV. 138 0 1 2 3 139 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 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Lower SC | Lower Encoding| Upper SC | Upper Encoding| 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Max LSP Bandwidth at priority 0 | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Max LSP Bandwidth at priority 1 | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Max LSP Bandwidth at priority 2 | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Max LSP Bandwidth at priority 3 | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Max LSP Bandwidth at priority 4 | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Max LSP Bandwidth at priority 5 | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Max LSP Bandwidth at priority 6 | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Max LSP Bandwidth at priority 7 | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Adjustment Capability-specific information | 160 | (variable) | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 [GMPLS-OTN-OSPF] defines attributes that identifies a layer in multi- 164 layer OTN ISCD. These attributes are part of Bandwidth sub-TLV in 165 Switch capability specific information of ISCD. These attributes are 166 reproduced here for completeness sake. 168 * Signal Type: Layer for which bandwidth is being advertised. 169 * Hierarchy : also called as multiplexing branch that specifies all 170 the layers between server layer and signal type. 171 * TSG : Time Slot Granularity 173 Adjustment Capability-specific information abbreviated as ACSI 174 henceforth for OTN G.709v3 carries LayerID Sub-TLV which is defined 175 as follows 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Type = 1 |R| Reserved | Length | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Signal type | Num of stages |TSG | Res | Stage#1 | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Stage#2 | ... | Stage#N | Padding | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 This LayerID sub-TLV is applicable only when one of the regions is 188 OTN, which means either lower or upper SC and Encoding type MUST have 189 Switch Cap as OTN-TDM and encoding type as G.709 ODUk. 191 R bit is used to make sense whether the Layer ID is for Lower region 192 or upper region. 1 means upper region and 0 means lower. 194 The 8 priorities of the BW as defined in main IACD structure, is 195 adjustment capability between the two regions where one of the region 196 is identifies by LayerID sub-TLV. 198 Absence of this sub-TLV for OTN means that the OTN ISCD doesn't 199 support multiplexing. 201 4 SONET/SDH Layer Identification 203 G.707 defines the structure of SDH multiplexing hierarchy and RFC 204 4606 defines generalized label structure needed to fully specify 205 SONET/SDH multiplexing hierarchy. This Label structure also referred 206 as SUKLM structure identifies all the layers of the multiplexing 207 hierarchy along with time slots. For the purpose of this draft, only 208 layer identification is needed, hence each layer can be identified by 209 a bit. Bit value 1 signifies presence of the layer and 0, its 210 absence. 5 Bits, each representing one layer is sufficient to fully 211 identify the SONET/SDH multiplexing hierarchy. 213 Layer ID sub TLV for SONET/SDH is defined as follows 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Type = 2 |R| Reserved | Length | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 |S|U|K|L|M| Padding | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 SUKLM bits signifies the presence of SONET/SDH layers and these bits 224 together fully specifies the multiplexing hierarchy. Refer to Section 225 3 of RFC 4606 for full specification of SUKLM bits. 227 Absence of sub-TLV means that the SONET/SDH ISCD doesn't support 228 multiplexing and needs only transparent mapping to other Interface. 230 5 Procedure 232 A node advertising IACD for the bandwidth between regions where one 233 or both of them are hierarchical i.e. OTN or SONET/SDH, MUST include 234 the Layer ID sub-TLV as part of ACSI as defined above. 236 For multi-region path computation, the path computing node MUST look 237 at the LayerID sub-TLV (in ACSI part of IACD) if lower/upper {SC,Enc] 238 is {OTN-TDM,G.709ODUk} or {TDM,SONET/SDH} to identify the layer for 239 correct layer for BW check. 241 6 Examples 243 This section exemplifies TLV values for various technology region 244 combinations, where one of the region is OTN 246 6.1. Ethernet and OTN When upper region is Ethernet and lower region 247 is OTN 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | PSC-1 | Ethernet | OTN-TDM | G.709 ODUk | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Max LSP Bandwidth at priority 0 | 254 | / / / / / / / / / / / / / / / | 255 | Max LSP Bandwidth at priority 7 | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Type = 1 |0| Reserved | Length | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Signal type | Num of stages |TSG | Res | Stage#1 | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Stage#2 | ... | Stage#N | Padding | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 6.2. OTN and FlexGrid 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | OTN-TDM | G.709 ODUk | SCSC | Lambda | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Max LSP Bandwidth at priority 0 | 271 | / / / / / / / / / / / / / / / | 272 | Max LSP Bandwidth at priority 7 | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Type = 1 |1| Reserved | Length | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Signal type | Num of stages |TSG | Res | Stage#1 | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Stage#2 | ... | Stage#N | Padding | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 6.3. OTN and SONET/SDH 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | OTN-TDM | G.709 ODUk | TDM | Sonet/SDH | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Max LSP Bandwidth at priority 0 | 288 | / / / / / / / / / / / / / / / | 289 | Max LSP Bandwidth at priority 7 | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Type = 1 |1| Reserved | Length | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Signal type | Num of stages |TSG | Res | Stage#1 | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Stage#2 | ... | Stage#N | Padding | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Type = 2 |0| Reserved | Length | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 |S|U|K|L|M| Padding | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 6.4. OTN and OTN 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | OTN-TDM | G.709 ODUk | OTN-TDM | G.709 ODUk | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Max LSP Bandwidth at priority 0 | 309 | / / / / / / / / / / / / / / / | 310 | Max LSP Bandwidth at priority 7 | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type = 1 |0| Reserved | Length | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Signal type | Num of stages |TSG | Res | Stage#1 | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Stage#2 | ... | Stage#N | Padding | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Type = 1 |1| Reserved | Length | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Signal type | Num of stages |TSG | Res | Stage#1 | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Stage#2 | ... | Stage#N | Padding | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 7 IANA Considerations 326 TBD 328 8 Security Considerations 330 TBD 332 9 References 334 [RFC5212] K. Shiomoto, Papadimitriou, D.,JL. Le Roux, Vigoureux, M., 335 Brungard, D., "Requirements for GMPLS-Based Multi-Layer 336 and Multi-Region Networks (MLN/ MRN)",RFC 5212, July 2008. 338 [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, 339 D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol 340 Extensions for Multi-Layer and Multi-Region Networks 341 (MLN/MRN)", RFC 6001, October 2010. 343 [RFC4606] E. Mannie, Perceval, D. Papadimitriou, "Generalized Multi- 344 Protocol Label Switching (GMPLS) Extensions for 345 Synchronous Optical Network (SONET) and Synchronous 346 Digital Hierarchy (SDH) Control", RFC 4606, Aug 2006 348 [GMPLS-OTN-OSPF] Traffic Engineering Extensions to OSPF for 349 Generalized MPLS (GMPLS)Control of Evolving G.709 OTN 350 Networks 352 10. Authors' Addresses 354 Khuzema Pithewan 355 Infinera 356 140 Caspian Ct., Sunnyvale, CA 94089 357 Email: kpithewan@infinera.com 359 Rajan Rao 360 Infinera 361 140 Caspian Ct., Sunnyvale, CA 94089 362 Email: rrao@infinera.com