idnits 2.17.1 draft-brockners-opsawg-ioam-deployment-02.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 7, 2020) is 1320 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC8126' is defined on line 867, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ali-spring-ioam-srv6-02 == Outdated reference: A later version (-05) exists of draft-brockners-ippm-ioam-geneve-04 == Outdated reference: A later version (-05) exists of draft-brockners-ippm-ioam-vxlan-gpe-03 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-10 == Outdated reference: A later version (-10) exists of draft-ietf-ippm-ioam-flags-02 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-ioam-ipv6-options-02 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-10 == Outdated reference: A later version (-13) exists of draft-ietf-sfc-ioam-nsh-04 == Outdated reference: A later version (-08) exists of draft-ietf-sfc-proof-of-transit-06 == Outdated reference: A later version (-06) exists of draft-mizrahi-ippm-ioam-profile-03 == Outdated reference: A later version (-07) exists of draft-spiegel-ippm-ioam-rawexport-03 == Outdated reference: A later version (-05) exists of draft-weis-ippm-ioam-eth-04 Summary: 0 errors (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 opsawg F. Brockners 3 Internet-Draft S. Bhandari 4 Intended status: Best Current Practice Cisco 5 Expires: March 11, 2021 D. Bernier 6 Bell Canada 7 September 7, 2020 9 In-situ OAM Deployment 10 draft-brockners-opsawg-ioam-deployment-02 12 Abstract 14 In-situ Operations, Administration, and Maintenance (IOAM) records 15 operational and telemetry information in the packet while the packet 16 traverses a path between two points in the network. This document 17 provides a framework for IOAM deployment and provides best current 18 practices. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 11, 2021. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. IOAM Deployment: Domains And Nodes . . . . . . . . . . . . . 4 57 4. Types of IOAM . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4.1. Per-hop Tracing IOAM . . . . . . . . . . . . . . . . . . 6 59 4.2. Proof of Transit IOAM . . . . . . . . . . . . . . . . . . 8 60 4.3. Edge to Edge IOAM . . . . . . . . . . . . . . . . . . . . 8 61 4.4. Direct Export IOAM . . . . . . . . . . . . . . . . . . . 8 62 5. IOAM Encapsulations . . . . . . . . . . . . . . . . . . . . . 8 63 5.1. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 5.2. NSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 5.3. GRE . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 5.4. Geneve . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5.5. Segment Routing . . . . . . . . . . . . . . . . . . . . . 9 68 5.6. Segment Routing for IPv6 . . . . . . . . . . . . . . . . 10 69 5.7. VXLAN-GPE . . . . . . . . . . . . . . . . . . . . . . . . 10 70 6. IOAM Data Export . . . . . . . . . . . . . . . . . . . . . . 10 71 7. IOAM Deployment Considerations . . . . . . . . . . . . . . . 11 72 7.1. IOAM Namespaces . . . . . . . . . . . . . . . . . . . . . 11 73 7.2. IOAM Layering . . . . . . . . . . . . . . . . . . . . . . 13 74 7.3. IOAM Trace Option Types . . . . . . . . . . . . . . . . . 14 75 7.4. Traffic-sets That IOAM Is Applied To . . . . . . . . . . 16 76 7.5. IOAM Loopback Mode . . . . . . . . . . . . . . . . . . . 16 77 7.6. IOAM Active Mode . . . . . . . . . . . . . . . . . . . . 16 78 7.7. Brown Field Deployments: IOAM Unaware Nodes . . . . . . . 17 79 8. IOAM Manageability . . . . . . . . . . . . . . . . . . . . . 17 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 81 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 82 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 85 12.2. Informative References . . . . . . . . . . . . . . . . . 19 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 88 1. Introduction 90 "In-situ" Operations, Administration, and Maintenance (IOAM) records 91 OAM information within the packet while the packet traverses a 92 particular network domain. The term "in-situ" refers to the fact 93 that the OAM data is added to the data packets rather than is being 94 sent within packets specifically dedicated to OAM. IOAM is to 95 complement mechanisms such as Ping, Traceroute, or other active 96 probing mechanisms. In terms of "active" or "passive" OAM, "in-situ" 97 OAM can be considered a hybrid OAM type. "In-situ" mechanisms do not 98 require extra packets to be sent. IOAM adds information to the 99 already available data packets and therefore cannot be considered 100 passive. In terms of the classification given in [RFC7799] IOAM 101 could be portrayed as Hybrid Type 1. IOAM mechanisms can be 102 leveraged where mechanisms using e.g. ICMP do not apply or do not 103 offer the desired results, such as proving that a certain traffic 104 flow takes a pre-defined path, SLA verification for the live data 105 traffic, detailed statistics on traffic distribution paths in 106 networks that distribute traffic across multiple paths, or scenarios 107 in which probe traffic is potentially handled differently from 108 regular data traffic by the network devices. 110 2. Conventions 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 Abbreviations used in this document: 118 E2E Edge to Edge 120 Geneve: Generic Network Virtualization Encapsulation 121 [I-D.ietf-nvo3-geneve] 123 GRE Generic Routing Encapsulation 125 IOAM: In-situ Operations, Administration, and Maintenance 127 MTU: Maximum Transmit Unit 129 NSH: Network Service Header [RFC8300] 131 OAM: Operations, Administration, and Maintenance 133 POT: Proof of Transit 135 SFC: Service Function Chain 137 SID: Segment Identifier 139 SR: Segment Routing 141 VXLAN-GPE: Virtual eXtensible Local Area Network, Generic Protocol 142 Extension [I-D.ietf-nvo3-vxlan-gpe] 144 3. IOAM Deployment: Domains And Nodes 146 IOAM is a network domain specific feature, with "network domain" 147 being a set of network devices or entities within a single 148 administration. IOAM is not targeted for a deployment on the global 149 Internet. The part of the network which employs IOAM is referred to 150 as the "IOAM-Domain". For example, an IOAM-domain can include an 151 enterprise campus using physical connections between devices or an 152 overlay network using virtual connections / tunnels for connectivity 153 between said devices. An IOAM-domain is defined by its perimeter or 154 edge. The operator of an IOAM-domain is expected to put provisions 155 in place to ensure that packets which contain IOAM data fields do not 156 leak beyond the edge of an IOAM domain, e.g. using for example packet 157 filtering methods. The operator should consider the potential 158 operational impact of IOAM to mechanisms such as ECMP processing 159 (e.g. load-balancing schemes based on packet length could be impacted 160 by the increased packet size due to IOAM), path MTU (i.e. ensure that 161 the MTU of all links within a domain is sufficiently large to support 162 the increased packet size due to IOAM) and ICMP message handling. 164 An IOAM-Domain consists of "IOAM encapsulating nodes", "IOAM 165 decapsulating nodes" and "IOAM transit nodes". The role of a node 166 (i.e. encapsulating, transit, decapsulating) is defined within an 167 IOAM-Namespace (see below). A node can have different roles in 168 different IOAM-Namespaces. 170 An "IOAM encapsulating node" incorporates one or more IOAM-Option- 171 Types into packets that IOAM is enabled for. If IOAM is enabled for 172 a selected subset of the traffic, the IOAM encapsulating node is 173 responsible for applying the IOAM functionality to the selected 174 subset. 176 An "IOAM transit node" updates one or more of the IOAM-Data-Fields. 177 If both the Pre-allocated and the Incremental Trace Option-Types are 178 present in the packet, each IOAM transit node will update at most one 179 of these Option-Types. A transit node does not add new IOAM-Option- 180 Types to a packet, and does not change the IOAM-Data-Fields of an 181 IOAM Edge-to-Edge Option-Type. 183 An "IOAM decapsulating node" removes IOAM-Option-Type(s) from 184 packets. 186 The role of an IOAM-encapsulating, IOAM-transit or IOAM-decapsulating 187 node is always performed within a specific IOAM-Namespace. This 188 means that an IOAM node which is e.g. an IOAM-decapsulating node for 189 IOAM-Namespace "A" but not for IOAM-Namespace "B" will only remove 190 the IOAM-Option-Types for IOAM-Namespace "A" from the packet. An 191 IOAM decapsulating node situated at the edge of an IOAM domain 192 removes all IOAM-Option-Types and associated encapsulation headers 193 for all IOAM-Namespaces from the packet. 195 IOAM-Namespaces allow for a namespace-specific definition and 196 interpretation of IOAM-Data-Fields. An interface-id could for 197 example point to a physical interface (e.g., to understand which 198 physical interface of an aggregated link is used when receiving or 199 transmitting a packet) whereas in another case it could refer to a 200 logical interface (e.g., in case of tunnels). Please refer to 201 Section 7.1 for a discussion of IOAM-Namespaces. 203 Export of Export of Export of Export of 204 IOAM data IOAM data IOAM data IOAM data 205 (optional) (optional) (optional) (optional) 206 ^ ^ ^ ^ 207 | | | | 208 | | | | 209 User +---+----+ +---+----+ +---+----+ +---+----+ 210 packets |Encapsu-| | Transit| | Transit| |Decapsu-| 211 -------->|lating |====>| Node |====>| Node |====>|lating |--> 212 |Node | | A | | B | |Node | 213 +--------+ +--------+ +--------+ +--------+ 215 Figure 1: Roles of IOAM nodes 217 IOAM nodes which add or remove the IOAM-Data-Fields can also update 218 the IOAM-Data-Fields at the same time. Or in other words, IOAM 219 encapsulating or decapsulating nodes can also serve as IOAM transit 220 nodes at the same time. Note that not every node in an IOAM domain 221 needs to be an IOAM transit node. For example, a deployment might 222 require that packets traverse a set of firewalls which support IOAM. 223 In that case, only the set of firewall nodes would be IOAM transit 224 nodes rather than all nodes. 226 4. Types of IOAM 228 IOAM supports different modes of operation, which are differentiated 229 by the type of IOAM data fields being carried in the packet, the data 230 being collected, the type of nodes which collect or update data as 231 well as whether and how nodes export IOAM information. 233 o Per-hop tracing: OAM information about each IOAM node a packet 234 traverses is collected and stored within the user data packet as 235 the packet progresses through the IOAM domain. Potential uses of 236 IOAM per-hop tracing include: 238 * Optimization: Understand the different paths different packets 239 traverse between a source and a sink in a network that uses 240 load balancing such as Equal Cost Load Balancing (ECMP). This 241 information could be used to tune the algorithm for ECMP for 242 optimized network resource usage. 244 * Operations/Troubleshooting: Understand which path a particular 245 packet or set of packets take as well as what amount of jitter 246 and delay different nodes in the path contribute to the overall 247 end-to-end delay and jitter. 249 o Proof-of-transit: Information that a verifier node can use to 250 verify whether a packet has traversed all nodes that is supposed 251 to traverse is stored within the user data packet. Proof-of- 252 transit could for example be used to verify that a packet indeed 253 passes through all services of a service function chain (e.g. 254 verify whether a packet indeed traversed the set of firewalls that 255 it is expected to traverse), or whether a packet indeed took the 256 expected path. 258 o Edge-to-edge: OAM information which is specific to the edges of an 259 IOAM domain is collected and stored within the user data packet. 260 Edge-to-Edge OAM could be used to gather operational information 261 about a particular network domain, such as the delay and jitter 262 incurred by that network domain or the traffic matrix of the 263 network domain. 265 o Direct export: OAM information about each IOAM node a packet 266 traverses is collected and immediately exported to a collector. 267 Direct export could be used in situations where per-hop tracing 268 information is desired, but gathering the information within the 269 packet - as with per-hop tracing - is not feasible. Rather than 270 automatically correlating the per-hop tracing information, as done 271 with per-hop tracing, direct export requires a collector to 272 correlate the information from the individual nodes. In addition, 273 all nodes enabled for direct export need to be capable to export 274 the IOAM information to the collector. 276 4.1. Per-hop Tracing IOAM 278 "IOAM tracing data" is expected to be collected at every IOAM transit 279 node that a packet traverses to ensure visibility into the entire 280 path a packet takes within an IOAM-Domain. I.e., in a typical 281 deployment all nodes in an IOAM-Domain would participate in IOAM and 282 thus be IOAM transit nodes, IOAM encapsulating or IOAM decapsulating 283 nodes. If not all nodes within a domain are IOAM capable, IOAM 284 tracing information (i.e., node data, see below) will only be 285 collected on those nodes which are IOAM capable. Nodes which are not 286 IOAM capable will forward the packet without any changes to the IOAM- 287 Data-Fields. The maximum number of hops and the minimum path MTU of 288 the IOAM domain is assumed to be known. 290 IOAM offers two different trace Option-Types, the "incremental" 291 Option-Type as well as the "pre-allocated" Option-Type. For a 292 discussion which of the two option types is the most suitable for an 293 implementation and/or deployment, see Section 7.3. 295 Every node data entry holds information for a particular IOAM transit 296 node that is traversed by a packet. The IOAM decapsulating node 297 removes the IOAM-Option-Type(s) and processes and/or exports the 298 associated data. All IOAM-Data-Fields are defined in the context of 299 an IOAM-Namespace. 301 IOAM tracing can collect the following types of information: 303 o Identification of the IOAM node. An IOAM node identifier can 304 match to a device identifier or a particular control point or 305 subsystem within a device. 307 o Identification of the interface that a packet was received on, 308 i.e. ingress interface. 310 o Identification of the interface that a packet was sent out on, 311 i.e. egress interface. 313 o Time of day when the packet was processed by the node as well as 314 the transit delay. Different definitions of processing time are 315 feasible and expected, though it is important that all devices of 316 an in-situ OAM domain follow the same definition. 318 o Generic data: Format-free information where syntax and semantic of 319 the information is defined by the operator in a specific 320 deployment. For a specific IOAM-Namespace, all IOAM nodes should 321 interpret the generic data the same way. Examples for generic 322 IOAM data include geo-location information (location of the node 323 at the time the packet was processed), buffer queue fill level or 324 cache fill level at the time the packet was processed, or even a 325 battery charge level. 327 o Information to detect whether IOAM trace data was added at every 328 hop or whether certain hops in the domain weren't IOAM transit 329 nodes. 331 o Data that relates to how the packet traversed a node (transit 332 delay, buffer occupancy in case the packet was buffered, queue 333 depth in case the packet was queued) 335 The Option-Types of incremental tracing and pre-allocated tracing are 336 defined in [I-D.ietf-ippm-ioam-data]. 338 4.2. Proof of Transit IOAM 340 IOAM Proof of Transit Option-Type is to support path or service 341 function chain [RFC7665] verification use cases. Proof-of-transit 342 uses methods like nested hashing or nested encryption of the IOAM 343 data or mechanisms such as Shamir's Secret Sharing Schema (SSSS). 345 The IOAM Proof of Transit Option-Type consist of a fixed size "IOAM 346 proof of transit option header" and "IOAM proof of transit option 347 data fields". For details see [I-D.ietf-ippm-ioam-data]. 349 4.3. Edge to Edge IOAM 351 The IOAM Edge-to-Edge Option-Type is to carry data that is added by 352 the IOAM encapsulating node and interpreted by IOAM decapsulating 353 node. The IOAM transit nodes may process the data but must not 354 modify it. 356 The IOAM Edge-to-Edge Option-Type consist of a fixed size "IOAM Edge- 357 to-Edge Option-Type header" and "IOAM Edge-to-Edge Option-Type data 358 fields". For details see [I-D.ietf-ippm-ioam-data]. 360 4.4. Direct Export IOAM 362 Direct Export is an IOAM mode of operation within which IOAM data to 363 be directly exported to a collector rather than being collected 364 within the data packets. The IOAM Direct Export Option-Type consist 365 of a fixed size "IOAM direct export option header". Direct Export 366 for IOAM is defined in [I-D.ioamteam-ippm-ioam-direct-export]. 368 5. IOAM Encapsulations 370 IOAM data fields and associated data types for in-situ OAM are 371 defined in [I-D.ietf-ippm-ioam-data]. The in-situ OAM data field can 372 be transported by a variety of transport protocols, including NSH, 373 Segment Routing, Geneve, IPv6, etc. 375 5.1. IPv6 377 IOAM encapsulation for IPv6 is defined in 378 [I-D.ietf-ippm-ioam-ipv6-options]. IOAM deployment considerations 379 for IPv6 networks are found in 380 [I-D.ioametal-ippm-6man-ioam-ipv6-deployment]. 382 5.2. NSH 384 IOAM encapsulation for NSH is defined in [I-D.ietf-sfc-ioam-nsh]. 386 5.3. GRE 388 IOAM encapsulation for GRE is outlined as part of the "EtherType 389 Protocol Identification of In-situ OAM Data" in 390 [I-D.weis-ippm-ioam-eth], though no example protocol header stacks 391 are provided in the document. When used with GRE, the IOAM-Option- 392 Types (the below diagram uses "IOAM" as shorthand for IOAM-Option- 393 Types) are sequenced in behind the GRE header that follows the 394 "outer" IP header. Figure 2 shows two example protocol header stacks 395 that use GRE along with IOAM. 397 Example 1 Example 2 399 | ... | | ... | 400 +----------------+ +----------------+ 401 | TCP/UDP header | | IP, ... | 402 +----------------+ +----------------+ 403 | IP header | | Eth. header | 404 +----------------+ +----------------+ 405 | IOAM | | IOAM | 406 +----------------+ +----------------+ 407 | GRE header | | GRE header | 408 +----------------+ +----------------+ 409 | IP header | | IP header | 410 +----------------+ +----------------+ 411 | Layer 2 | | Layer 2 | 412 +----------------+ +----------------+ 413 | Layer 1 | | Layer 1 | 414 +----------------+ +----------------+ 416 Figure 2: GRE with IOAM examples 418 5.4. Geneve 420 IOAM encapsulation for Geneve is defined in 421 [I-D.brockners-ippm-ioam-geneve]. 423 5.5. Segment Routing 425 IOAM encapsulation for Segment Routing is defined in 426 [I-D.gandhi-spring-ioam-sr-mpls]. 428 5.6. Segment Routing for IPv6 430 IOAM encapsulation for Segment Routing over IPv6 is defined in 431 [I-D.ali-spring-ioam-srv6]. 433 5.7. VXLAN-GPE 435 IOAM encapsulation for VXLAN-GPE is defined in 436 [I-D.brockners-ippm-ioam-vxlan-gpe]. 438 6. IOAM Data Export 440 IOAM nodes collect information for packets traversing a domain that 441 supports IOAM. IOAM decapsulating nodes as well as IOAM transit 442 nodes can choose to retrieve IOAM information from the packet, 443 process the information further and export the information using 444 e.g., IPFIX. 446 Raw data export of IOAM data using IPFIX is discussed in 447 [I-D.spiegel-ippm-ioam-rawexport]. "Raw export of IOAM data" refers 448 to a mode of operation where a node exports the IOAM data as it is 449 received in the packet. The exporting node neither interprets, 450 aggregates nor reformats the IOAM data before it is exported. Raw 451 export of IOAM data is to support an operational model where the 452 processing and interpretation of IOAM data is decoupled from the 453 operation of encapsulating/updating/decapsulating IOAM data, which is 454 also referred to as IOAM data-plane operation. The figure below 455 shows the separation of concerns for IOAM export: Exporting IOAM data 456 is performed by the "IOAM node" which performs IOAM data-plane 457 operation, whereas the interpretation of IOAM data is performed by 458 one or several IOAM data processing systems. The separation of 459 concerns is to off-load interpretation, aggregation and formatting of 460 IOAM data from the node which performs data-plane operations. In 461 other words, a node which is focused on data-plane operations, i.e. 462 forwarding of packets and handling IOAM data will not be tasked to 463 also interpret the IOAM data, but can leave this task to another 464 system or a set of systems. For scalability reasons, a single IOAM 465 node could choose to export IOAM data to several IOAM data processing 466 systems. Similarly, there several monitoring systems or analytics 467 systems can be used to further process the data received from the 468 IOAM preprocessing systems. Figure 3 shows an overview of IOAM 469 export, including IOAM data processing systems and monitoring/ 470 analytics systems. 472 +--------------+ 473 +-------------+ | 474 | Monitoring/ | | 475 | Analytics | | 476 | system(s) |-+ 477 +-------------+ 478 ^ 479 | Processed/interpreted/ 480 | aggregated IOAM data 481 | 482 +--------------+ 483 +-------------+ | 484 | IOAM data | | 485 | processing | | 486 | system(s) |-+ 487 +-------------+ 488 ^ 489 | Raw export of 490 | IOAM data 491 | 492 +--------------+-------+------+--------------+ 493 | | | | 494 | | | | 495 User +---+----+ +---+----+ +---+----+ +---+----+ 496 packets |Encapsu-| | Transit| | Transit| |Decapsu-| 497 -------->|lating |====>| Node |====>| Node |====>|lating |--> 498 |Node | | A | | B | |Node | 499 +--------+ +--------+ +--------+ +--------+ 501 Figure 3: IOAM framework with data export 503 7. IOAM Deployment Considerations 505 This section discusses several aspects of an IOAM deployment, 506 including IOAM Namespaces, IOAM Layering, traffic-sets that IOAM is 507 applied to and IOAM loopback mode. 509 7.1. IOAM Namespaces 511 IOAM-Namespaces add further context to IOAM-Option-Types and 512 associated IOAM-Data-Fields. IOAM-Namespaces support several 513 different uses: 515 o IOAM-Namespaces can be used by an operator to distinguish 516 different operational domains. Devices at domain edges can filter 517 on Namespace-IDs to provide for proper IOAM-Domain isolation. 519 o IOAM-Namespaces provide additional context for IOAM-Data-Fields 520 and thus ensure that IOAM-Data-Fields are unique and can be 521 interpreted properly by management stations or network 522 controllers. While, for example, the node identifier field does 523 not need to be unique in a deployment (e.g. an operator may wish 524 to use different node identifiers for different IOAM layers, even 525 within the same device; or node identifiers might not be unique 526 for other organizational reasons, such as after a merger of two 527 formerly separated organizations), the combination of node_id and 528 Namespace-ID will always be unique. Similarly, IOAM-Namespaces 529 can be used to define how certain IOAM-Data-Fields are 530 interpreted: IOAM offers three different timestamp format options. 531 The Namespace-ID can be used to determine the timestamp format. 532 IOAM-Data-Fields (e.g. buffer occupancy) which do not have a unit 533 associated are to be interpreted within the context of a IOAM- 534 Namespace. 536 o IOAM-Namespaces can be used to identify different sets of devices 537 (e.g., different types of devices) in a deployment: If an operator 538 desires to insert different IOAM-Data-Fields based on the device, 539 the devices could be grouped into multiple IOAM-Namespaces. This 540 could be due to the fact that the IOAM feature set differs between 541 different sets of devices, or it could be for reasons of optimized 542 space usage in the packet header. It could also stem from 543 hardware or operational limitations on the size of the trace data 544 that can be added and processed, preventing collection of a full 545 trace for a flow. 547 * Assigning different IOAM Namespace-IDs to different sets of 548 nodes or network partitions and using the Namespace-ID as a 549 selector at the IOAM encapsulating node, a full trace for a 550 flow could be collected and constructed via partial traces in 551 different packets of the same flow. Example: An operator could 552 choose to group the devices of a domain into two IOAM- 553 Namespaces, in a way that at average, only every second hop 554 would be recorded by any device. To retrieve a full view of 555 the deployment, the captured IOAM-Data-Fields of the two IOAM- 556 Namespaces need to be correlated. 558 * Assigning different IOAM Namespace-IDs to different sets of 559 nodes or network partitions and using a separate instance of an 560 IOAM-Option-Type for each Namespace-ID, a full trace for a flow 561 could be collected and constructed via partial traces from each 562 IOAM-Option-Type in each of the packets in the flow. Example: 563 An operator could choose to group the devices of a domain into 564 two IOAM-Namespaces, in a way that each IOAM-Namespace is 565 represented by one of two IOAM-Option-Types in the packet. 566 Each node would record data only for the IOAM-Namespace that it 567 belongs to, ignoring the other IOAM-Option-Type with a IOAM- 568 Namespace to which it doesn't belong. To retrieve a full view 569 of the deployment, the captured IOAM-Data-Fields of the two 570 IOAM-Namespaces need to be correlated. 572 7.2. IOAM Layering 574 If several encapsulation protocols (e.g., in case of tunneling) are 575 stacked on top of each other, IOAM-Data-Fields could be present in 576 different protocol fields at different layers. Layering allows 577 operators to instrument the protocol layer they want to measure. The 578 behavior follows the ships-in-the-night model, i.e. IOAM-Data-Fields 579 in one layer are independent from IOAM-Data-Fields in another layer. 580 Or in other words: Even though the term "layering" often implies some 581 form of hierarchy and relationship, in IOAM, layers are independent 582 from each other and don't assume any relationship among them. The 583 different layers could, but do not have to share the same IOAM 584 encapsulation mechanisms. Similarly, the sematics of the IOAM-Data- 585 Fields, can, do not have to be associated to across different layers. 586 For example, a node which inserts node-id information into two 587 different layers could use "node-id=10" for one layer and "node- 588 id=1000" for the second layer. 590 Figure 4 shows an example of IOAM layering. The figure shows a 591 Geneve tunnel carried over IPv6 which starts at node A and ends at 592 node D. IOAM information is encapsulated in IPv6 as well as in 593 Geneve. At the IPv6 layer, node A is IOAM encapsulating node (into 594 IPv6), node D is the IOAM decapsulating node and node B and node C 595 are IOAM transit nodes. At the Geneve layer, node A is IOAM 596 encapsulating node (into Geneve) and node D is IOAM decapsulating 597 node (from Geneve). The use of IOAM at both layers as shown in the 598 example here could be used to reveal which nodes of an underlay (here 599 the IPv6 network) are traversed by tunneled packet in an overlay 600 (here the Geneve network) - which assumes that the IOAM information 601 encapsulated by nodes A and D into Geneve and IPv6 is associated to 602 each other. 604 +---+----+ +---+----+ 605 User |Geneve | |Geneve | 606 packets |Encapsu-| |Decapsu-| 607 -------->|lating |==================================>|lating |--> 608 | Node | | Node | 609 | A | | D | 610 +--------+ +--------+ 611 ^ ^ 612 | | 613 v v 614 +--------+ +--------+ +--------+ +--------+ 615 |IPv6 | | IPv6 | | IPv6 | |IPv6 | 616 |Encapsu-| | Transit| | Transit| |Decapsu-| 617 |lating |====>| Node |====>| Node |====>|lating | 618 | Node | | | | | | Node | 619 | A | | B | | C | | D | 620 +--------+ +--------+ +--------+ +--------+ 622 Figure 4: IOAM layering example 624 7.3. IOAM Trace Option Types 626 IOAM offers two different IOAM Option-Types for tracing: 627 "Incremental" Trace-Option-Type and "Pre-allocated" Trace-Option- 628 Type. "Incremental" refers to a mode of operation where the packet 629 is expanded at every IOAM node that addes IOAM-Data-Fields. "Pre- 630 Allocated" describes a mode of operation where the IOAM encapsulating 631 node allocates room for all IOAM-Data-Fields in the entire IOAM 632 domain. More specifically: 634 Pre-allocated Trace-Option: This trace option is defined as a 635 container of node data fields with pre-allocated space for each 636 node to populate its information. This option is useful for 637 implementations where it is efficient to allocate the space once 638 and index into the array to populate the data during transit 639 (e.g., software forwarders often fall into this class). 641 Incremental Trace-Option: This trace option is defined as a 642 container of node data fields where each node allocates and pushes 643 its node data immediately following the option header. 645 A deployment can choose to configure and support one or both of the 646 IOAM Trace-Option-Types. The operator decides by means of 647 configuration which Trace-Option-Type(s) will be used for a 648 particular domain. Deployments can mix devices which include either 649 the Incremental Trace-Option-Type or the Pre-allocated Trace-Option- 650 Type, e.g. in case different types of packet forwarders and 651 associated different types of IOAM implementations exist in a 652 deployment. As a result, both Option-Types can be present in a 653 packet. IOAM decapsulating nodes remove both types of Trace-Option- 654 Types from the packet. 656 The two different Option-Types cater to different packet forwarding 657 infrastructures and are to allow an optimized implementation of IOAM 658 tracing: 660 Pre-allocated Trace-Option: For some implementations of packet 661 forwarders it is efficient to allocate the space for the maximum 662 number of nodes that IOAM Trace Data-Fields should be collected 663 from and insert/update information in the packet at flexible 664 locations, based on a pointer retrieved from a field in the 665 packet. The IOAM encapsulating node allocates an array of the 666 size of the maximum number of nodes that IOAM Trace Data-Fields 667 should be collected from. IOAM transit nodes index into the array 668 to populate the data during transit. Software forwarders often 669 fall into this class of packet forwarder implementations. The 670 maximum number of nodes that IOAM information could be collected 671 from is configured by the operator on the IOAM encapsulating node. 672 The operator has to ensure that the packet with the pre-allocated 673 array that carries the IOAM Data-Fields does not exceed the MTU of 674 any of the links in the IOAM domain. 676 Incremental Trace-Option: Looking up a pointer contained in the 677 packet and inserting/updating information at a flexible location 678 in the packet as a result of the pointer lookup is costly for some 679 forwarding infrastructures. Hardware-based packet forwarding 680 infrastructures often fall into this category. Consequently, 681 hardware-based packet forwarders could choose to support the 682 incremental IOAM-Trace-Option-Type. The incremental IOAM-Trace- 683 Option-Type eliminates the need for the IOAM transit nodes to read 684 the full array in the Trace-Option-Type and allows packets to grow 685 to the size of the MTU of the IOAM domain. IOAM transit nodes 686 will expand the packet and insert the IOAM-Data-Fields as long as 687 there is space available in the packet, i.e. as long as the size 688 of the packet stays within the bounds of the MTU of any of the 689 links in the IOAM domain. There is no need for the operator to 690 configure the IOAM encapsulation node with the maximum number of 691 nodes that IOAM information could be collected from. The operator 692 has to ensure that the minimum MTU of any of the links in the IOAM 693 domain is known to all IOAM transit nodes. 695 7.4. Traffic-sets That IOAM Is Applied To 697 IOAM can be deployed on all or only on subsets of the live user 698 traffic,e.g. per interface, based on an access control list or flow 699 specification defining a specific set of traffic, etc. 701 7.5. IOAM Loopback Mode 703 IOAM Loopback is used to trigger each transit device along the path 704 of a packet to send a copy of the data packet back to the source. 705 Loopback allows an IOAM encapsulating node to trace the path to a 706 given destination, and to receive per-hop data about both the forward 707 and the return path. Loopback is enabled by the encapsulating node 708 setting the loopback flag. Looped-back packets use the source 709 address of the original packet as destination address and the address 710 of the node which performs the loopback operation as source address. 711 Nodes which loop back a packet clear the loopback flag before sending 712 the copy back towards the source. Loopack applies to IOAM 713 deployments where the encapsulating node is either a host or the 714 start of a tunnel: For details on IOAM loopback, please refer to 715 [I-D.ietf-ippm-ioam-flags]. 717 7.6. IOAM Active Mode 719 The IOAM active mode flag indicates that a packet is an active OAM 720 packet as opposed to regular user data traffic. Active mode is 721 expected to be used for active measurement using IOAM. Example use- 722 cases include: 724 o Endpoint detailed active measurement: Synthetic probe packets are 725 sent between the source and destination, traversing the IOAM 726 domain. These probe packets include a Trace Option-Type (i.e., 727 either incremental or pre-allocated). Since the probe packets are 728 sent between the endpoints, these packets are treated as data 729 packets by the IOAM domain, and do not require special treatment 730 at the IOAM layer.The encapsulating node can choose to set the 731 Active flag, providing an explicit indication that these probe 732 packets are meant for telemetry collection. 734 o IOAM active measurement using probe packets: Probe packets are 735 generated and transmitted by the IOAM encapsulating node, and are 736 expected to be terminated by the decapsulating node. Probe 737 packets include a Trace Option-Type (i.e., either incremental or 738 pre-allocated) which has its Active flag set, indicating that the 739 decapsulating node must terminate them. 741 o IOAM active measurement using replicated data packets: Probe 742 packets are created by the encapsulating node by selecting some or 743 all of the en route data packets and replicating them. A selected 744 data packet that is replicated, and its (possibly truncated) copy 745 is forwarded with one or more IOAM option, while the original 746 packet is forwarded normally, without IOAM options. To the extent 747 possible, the original data packet and its replica are forwarded 748 through the same path. The replica includes a Trace Option-Type 749 that has its Active flag set, indicating that the decapsulating 750 node should terminate it. 752 For details on IOAM active mode, please refer to 753 [I-D.ietf-ippm-ioam-flags]. 755 7.7. Brown Field Deployments: IOAM Unaware Nodes 757 A network can consist of a mix of IOAM aware and IOAM unaware nodes. 758 The encapsulation of IOAM-Data-Fields into different protocols (see 759 also Section 5) are defined such that data packets that include IOAM- 760 Data-Fields do not get dropped by IOAM unaware nodes. For example, 761 packets which contain the IOAM-Trace-Option-Types in IPv6 Hop by Hop 762 extension headers are defined with bits to indicate "00 - skip over 763 this option and continue processing the header". This will ensure 764 that when a node that is IOAM unaware receives a packet with IOAM- 765 Data-Fields included, does not drop the packet. 767 Deployments which leverage the IOAM-Trace-Option-Type(s) could 768 benefit from the ability to detect the presence of IOAM unaware 769 nodes, i.e. nodes which forward the packet but do not update/add 770 IOAM-Data-Fields in IOAM-Trace-Option-Type(s). The node data that is 771 defined as part of the IOAM-Trace-Option-Type(s) includes a Hop_Lim 772 field associated to the node identifier to detect missed nodes, i.e. 773 "holes" in the trace. Monitoring/Analytics system(s) could utilize 774 this information to account for the presence of IOAM unaware nodes in 775 the network. 777 8. IOAM Manageability 779 The YANG model for configuring IOAM in network nodes which support 780 IOAM is defined in [I-D.zhou-ippm-ioam-yang]. 782 A deployment can leverage IOAM profiles is to limit the scope of IOAM 783 features, allowing simpler implementation, verification, and 784 interoperability testing in the context of specific use cases that do 785 not require the full functionality of IOAM. An IOAM profile defines 786 a use case or a set of use cases for IOAM, and an associated set of 787 rules that restrict the scope and features of the IOAM specification, 788 thereby limiting it to a subset of the full functionality. IOAM 789 profiles are defined in [I-D.mizrahi-ippm-ioam-profile]. 791 9. IANA Considerations 793 This document does not request any IANA actions. 795 10. Security Considerations 797 As discussed in [RFC7276], a successful attack on an OAM protocol in 798 general, and specifically on IOAM, can prevent the detection of 799 failures or anomalies, or create a false illusion of nonexistent 800 ones. 802 The Proof of Transit Option-Type (Section Section 4.2) is used for 803 verifying the path of data packets. The security considerations of 804 POT are further discussed in [I-D.ietf-sfc-proof-of-transit]. 806 Security considerations related to the use of IOAM flags, in 807 particular the loopback flag are found in [I-D.ietf-ippm-ioam-flags]. 809 The data elements of IOAM can be used for network reconnaissance, 810 allowing attackers to collect information about network paths, 811 performance, queue states, buffer occupancy and other information. 812 Note that in case IOAM is used in "immediate export" mode (reference 813 to be added in a future revision), the IOAM related trace information 814 would not be available in the customer data packets, but would 815 trigger export of packet related IOAM information at every node. 816 IOAM data export and securing IOAM data export is outside the scope 817 of this document. 819 IOAM can be used as a means for implementing Denial of Service (DoS) 820 attacks, or for amplifying them. For example, a malicious attacker 821 can add an IOAM header to packets in order to consume the resources 822 of network devices that take part in IOAM or collectors that analyze 823 the IOAM data. Another example is a packet length attack, in which 824 an attacker pushes headers associated with IOAM Option-Types into 825 data packets, causing these packets to be increased beyond the MTU 826 size, resulting in fragmentation or in packet drops. 828 Since IOAM options may include timestamps, if network devices use 829 synchronization protocols then any attack on the time protocol 830 [RFC7384] can compromise the integrity of the timestamp-related data 831 fields. 833 At the management plane, attacks may be implemented by misconfiguring 834 or by maliciously configuring IOAM-enabled nodes in a way that 835 enables other attacks. Thus, IOAM configuration should be secured in 836 a way that authenticates authorized users and verifies the integrity 837 of configuration procedures. 839 Notably, IOAM is expected to be deployed in specific network domains, 840 thus confining the potential attack vectors to within the network 841 domain. Indeed, in order to limit the scope of threats to within the 842 current network domain the network operator is expected to enforce 843 policies that prevent IOAM traffic from leaking outside of the IOAM 844 domain, and prevent IOAM data from outside the domain to be processed 845 and used within the domain. Note that the Immediate Export mode 846 (reference to be added in a future revision) can mitigate the 847 potential threat of IOAM data leaking through data packets. 849 11. Acknowledgements 851 The authors would like to thank Tal Mizrahi, Eric Vyncke, Nalini 852 Elkins, Srihari Raghavan, Ranganathan T S, Barak Gafni, Karthik Babu 853 Harichandra Babu, Akshaya Nadahalli, LJ Wobker, Erik Nordmark, 854 Vengada Prasad Govindan, Andrew Yourtchenko, Aviv Kfir, Tianran Zhou, 855 Zhenbin (Robin), Joe Clarke, Al Morton, Tom Herbet, Haoyu song, and 856 Mickey Spiegel for the comments and advice on IOAM. 858 12. References 860 12.1. Normative References 862 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 863 Requirement Levels", BCP 14, RFC 2119, 864 DOI 10.17487/RFC2119, March 1997, 865 . 867 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 868 Writing an IANA Considerations Section in RFCs", BCP 26, 869 RFC 8126, DOI 10.17487/RFC8126, June 2017, 870 . 872 12.2. Informative References 874 [I-D.ali-spring-ioam-srv6] 875 Ali, Z., Gandhi, R., Filsfils, C., Brockners, F., Kumar, 876 N., Pignataro, C., Li, C., Chen, M., and G. Dawra, 877 "Segment Routing Header encapsulation for In-situ OAM 878 Data", draft-ali-spring-ioam-srv6-02 (work in progress), 879 November 2019. 881 [I-D.brockners-ippm-ioam-geneve] 882 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 883 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Lapukhov, 884 P., Gafni, B., Kfir, A., and M. Spiegel, "Geneve 885 encapsulation for In-situ OAM Data", draft-brockners-ippm- 886 ioam-geneve-04 (work in progress), May 2020. 888 [I-D.brockners-ippm-ioam-vxlan-gpe] 889 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 890 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A., 891 Gafni, B., Lapukhov, P., and M. Spiegel, "VXLAN-GPE 892 Encapsulation for In-situ OAM Data", draft-brockners-ippm- 893 ioam-vxlan-gpe-03 (work in progress), November 2019. 895 [I-D.gandhi-spring-ioam-sr-mpls] 896 Gandhi, R., Ali, Z., Filsfils, C., Brockners, F., Wen, B., 897 and V. Kozak, "Segment Routing with MPLS Data Plane 898 Encapsulation for In-situ OAM Data", draft-gandhi-spring- 899 ioam-sr-mpls-02 (work in progress), August 2019. 901 [I-D.ietf-ippm-ioam-data] 902 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 903 for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in 904 progress), July 2020. 906 [I-D.ietf-ippm-ioam-flags] 907 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 908 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. 909 Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-02 910 (work in progress), July 2020. 912 [I-D.ietf-ippm-ioam-ipv6-options] 913 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 914 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 915 Lapukhov, P., Spiegel, M., Krishnan, S., and R. Asati, 916 "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- 917 ipv6-options-02 (work in progress), July 2020. 919 [I-D.ietf-nvo3-geneve] 920 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 921 Network Virtualization Encapsulation", draft-ietf- 922 nvo3-geneve-16 (work in progress), March 2020. 924 [I-D.ietf-nvo3-vxlan-gpe] 925 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 926 Extension for VXLAN (VXLAN-GPE)", draft-ietf-nvo3-vxlan- 927 gpe-10 (work in progress), July 2020. 929 [I-D.ietf-sfc-ioam-nsh] 930 Brockners, F. and S. Bhandari, "Network Service Header 931 (NSH) Encapsulation for In-situ OAM (IOAM) Data", draft- 932 ietf-sfc-ioam-nsh-04 (work in progress), June 2020. 934 [I-D.ietf-sfc-proof-of-transit] 935 Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S. 936 Youell, "Proof of Transit", draft-ietf-sfc-proof-of- 937 transit-06 (work in progress), June 2020. 939 [I-D.ioametal-ippm-6man-ioam-ipv6-deployment] 940 Bhandari, S., Brockners, F., Mizrahi, T., Kfir, A., Gafni, 941 B., Spiegel, M., Krishnan, S., and M. Smith, "Deployment 942 Considerations for In-situ OAM with IPv6 Options", draft- 943 ioametal-ippm-6man-ioam-ipv6-deployment-03 (work in 944 progress), March 2020. 946 [I-D.ioamteam-ippm-ioam-direct-export] 947 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 948 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 949 OAM Direct Exporting", draft-ioamteam-ippm-ioam-direct- 950 export-00 (work in progress), October 2019. 952 [I-D.mizrahi-ippm-ioam-profile] 953 Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., 954 Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., Zhou, T., 955 and J. Lemon, "In Situ OAM Profiles", draft-mizrahi-ippm- 956 ioam-profile-03 (work in progress), August 2020. 958 [I-D.spiegel-ippm-ioam-rawexport] 959 Spiegel, M., Brockners, F., Bhandari, S., and R. 960 Sivakolundu, "In-situ OAM raw data export with IPFIX", 961 draft-spiegel-ippm-ioam-rawexport-03 (work in progress), 962 March 2020. 964 [I-D.weis-ippm-ioam-eth] 965 Weis, B., Brockners, F., Hill, C., Bhandari, S., Govindan, 966 V., Pignataro, C., Gredler, H., Leddy, J., Youell, S., 967 Mizrahi, T., Kfir, A., Gafni, B., Lapukhov, P., and M. 968 Spiegel, "EtherType Protocol Identification of In-situ OAM 969 Data", draft-weis-ippm-ioam-eth-04 (work in progress), May 970 2020. 972 [I-D.zhou-ippm-ioam-yang] 973 Zhou, T., Guichard, J., Brockners, F., and S. Raghavan, "A 974 YANG Data Model for In-Situ OAM", draft-zhou-ippm-ioam- 975 yang-08 (work in progress), July 2020. 977 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 978 Weingarten, "An Overview of Operations, Administration, 979 and Maintenance (OAM) Tools", RFC 7276, 980 DOI 10.17487/RFC7276, June 2014, 981 . 983 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 984 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 985 October 2014, . 987 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 988 Chaining (SFC) Architecture", RFC 7665, 989 DOI 10.17487/RFC7665, October 2015, 990 . 992 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 993 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 994 May 2016, . 996 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 997 "Network Service Header (NSH)", RFC 8300, 998 DOI 10.17487/RFC8300, January 2018, 999 . 1001 Authors' Addresses 1003 Frank Brockners 1004 Cisco Systems, Inc. 1005 Hansaallee 249, 3rd Floor 1006 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 1007 Germany 1009 Email: fbrockne@cisco.com 1011 Shwetha Bhandari 1012 Cisco Systems, Inc. 1013 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 1014 Bangalore, KARNATAKA 560 087 1015 India 1017 Email: shwethab@cisco.com 1019 Daniel Bernier 1020 Bell Canada 1021 Canada 1023 Email: daniel.bernier@bell.ca