idnits 2.17.1 draft-king-opsawg-time-multi-layer-oam-use-case-01.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 (July 4, 2014) is 3577 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-ww-opsawg-multi-layer-oam-01 == Outdated reference: A later version (-06) exists of draft-boucadair-sfc-requirements-05 == Outdated reference: A later version (-13) exists of draft-ietf-sfc-problem-statement-07 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operations and Management Area Working Group D. King 3 Internet-Draft Old Dog Consulting 4 Intended status: Informational M. Boucadair 5 Expires: January 5, 2015 France Telecom 6 S. Aldrin 7 Huawei USA 8 G. Mirsky 9 Ericsson 10 Q. Wu 11 Huawei 12 July 4, 2014 14 Use Cases and Requirements for Transport-Independent Multiple Layer OAM 15 draft-king-opsawg-time-multi-layer-oam-use-case-01 17 Abstract 19 This document identifies and discusses use-cases and high level 20 requirements for transport technology independent OAM that need to 21 interface multi-layer or multi-domain transport networks to cover 22 heterogeneous networking technologies. As providers face multi-layer 23 networks and diverse transport technologies, generic and integrated 24 OAM is desirable for simplifying network operations and maintenance. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 5, 2015. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Conventions used in this document . . . . . . . . . . . . 3 63 2.2. Acronyms and Abbreviations . . . . . . . . . . . . . . . 3 64 3. Multi-Layer OAM use cases illustration . . . . . . . . . . . 4 65 3.1. Multi-layer multi-domain OAM Consolidated in the Data 66 Plane and Management Plane . . . . . . . . . . . . . . . 4 67 3.2. OAM at Top of Layer 3 . . . . . . . . . . . . . . . . . . 5 68 3.3. Overlay OAM . . . . . . . . . . . . . . . . . . . . . . . 7 69 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 7.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 This document discusses use-cases for transport-independent OAM that 80 need to interface multi-layer or multi-domain transport networks to 81 cover heterogeneous networking technologies. As providers (e.g., 82 network providers, data center providers, etc.) face multi-layer 83 networks and diverse transport technologies, generic and integrated 84 OAM is desirable for keeping network complexity down and simplifying 85 O&M (OAM and O&M are used as specified in [RFC6291]). 87 This document is part of Transport Independent OAM in Multi-Layer 88 Environment (TIME) effort which is meant to: 90 o Understand and discuss situations where an OAM protocol can be 91 tuned and optimized for a specific data plane. 93 o OAM consolidations in the data plane: 95 * Exchange OAM information at the service layer atop of layer 3. 97 * Deployed over various encapsulating protocols, and in various 98 medium types. 100 o OAM consolidations in the management plane: 102 * Abstract OAM information common to different layers. 104 * Expose OAM information via unified interface to management 105 entities, independently of the layer they belong to. 107 * Discuss how information gathered from various layers can be 108 correlated for the sake of network operations optimization 109 purposes. 111 * Propose means to help during service diagnosis; these means may 112 rely on filtering information to be leaked to other layers so 113 that time recovery can be optimized. A typical example would 114 be efficient root cause analysis that is fed with input from 115 various layers. 117 * Propose means that would help to optimize a network as a whole 118 instead of the monolithic approach that is specific to a given 119 layer. For example, investigate means that would help in 120 computing diverse and completely disjoint paths, not only at 121 layer 3 but also at the physical layer. 123 These objectives are not frozen; further discussion is required to 124 target key issues and scope the work to be conducted within IETF 125 accordingly. 127 The problem statement and architecture is discussed in [TIME-PS]. 129 2. Terminology 131 2.1. Conventions used in this document 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC2119 [RFC2119]. 137 2.2. Acronyms and Abbreviations 139 TIME - Transport Independent OAM in Multi-Layer Environment 141 OAM - Operations, Administration, and Maintenance 143 O&M - OAM and Management 145 3. Multi-Layer OAM use cases illustration 147 3.1. Multi-layer multi-domain OAM Consolidated in the Data Plane and 148 Management Plane 150 Figure 1 illustrates a multi-layer network in which IP traffic 151 between two customer edges is transported over both an IP/MPLS 152 provider network and an Ethernet/MPLS provider network and multiple 153 layers OAM are used. Ethernet OAM is used at the customer level for 154 monitoring the end-to-end connection between the two customer edges, 155 while IP OAM and MPLS OAM is used at the provider level for 156 monitoring the connection between any two provider edges in each 157 network. In addition to Ethernet OAM, transport independent OAM is 158 also used for monitor end to end connection between the two customer 159 edges at the abstract level. 161 Domain A Domain B 162 ---------- ---------- 163 //-IP/MPLS -\\ //Ethernet/MPLS 164 // \\ // \\ 165 / \ / \ 166 || || || || 167 | | | | 168 +---+ +----+ +----+ +-------+ +----+ +----+ +---+ 169 |CE |--| PE |------| P +---- | PE | ---- | P |-----| PE |--|CE | 170 +-+-+ +--+-+ +--+-+ +---+---+ +--+-+ +-+--+ +-+-+ 171 | | | | | | | | | | | 172 | ||| | || | || | ||| | 173 | | | | | | | | | 174 | |\\ | // | \\ | //| | 175 | | \\- | -// | \\- | -// | | 176 | | ------+--- | -----+---- | | 177 L1 | |Ethernet OAM(CC,CV,etc.) | | | 178 o-------D-----------+--------+---o---+----------+---------D-------o 179 | | | | | | | 180 L2| | |IP OAM(Ping,|Traceroute, etc.) | | 181 o-------o-----------D-------- ---o--- ----------D---------o-------o 182 | | | | | | | 183 L?| Transport Independent OAM(Integrated Ethernet with IP OAM | 184 o-------o-----------D-------- ---o--- ----------D---------o-------o 185 | | | | | | | 186 | | | | | | | 188 o Maintenance Endpoint(MEP) 189 D Maintenance Intermediary point (MIP) 191 Figure 1: Multi-Domain Multi-Layer OAM 193 With transport independent OAM in the data plane, a user who wishes 194 to issue a IP Ping Command or use connectivity verification command 195 can do so in the same manner regardless of the underlying protocol or 196 transport technology. Consider a scenario where both Ethernet OAM 197 and IP OAM can be decomposed into a set of various OAM functions and 198 an Ethernet OAM can be integrated with IP OAM in one protocol. When 199 one OAM function is invoked, it will be invoked in the same way as 200 the other OAM function regardless of the underlying protocol. 202 Alternatively, when Ethernet OAM and IP OAM can be consolidated 203 through uniformed interface at the management plane, A user who 204 wishes to issue a IP Ping command or a IP Traceroute or initiate a 205 session monitoring can also do so in the same manner regardless of 206 the underlying protocol or technology. 208 Consider a scenario where an IP ping to PE B from CE A failed. 209 Between CE A and PE B there are IEEE 802.1 [IEEE-802.1Q] bridges a,b 210 and c. Let's assume a,b and c are using [IEEE-802.1ag] CFM. Upon 211 detecting IP layer ping failure, the user may wish to "go down" to 212 the Ethernet layer and issue the corresponding fault verification 213 (LBM/LBR) and fault isolation (LTM/LTR) tools, using the same API. 215 3.2. OAM at Top of Layer 3 217 In Service Function Chain ([I-D.ietf-sfc-problem-statement]), the 218 service packets are steered through a set of Service Function Nodes 219 distributed in the network. Overlay technologies (or tunneling 220 techniques in general) can be used to stitch these Service Function 221 Nodes in order to form end to end path (see Figure 2). 223 +--------+ 224 |Unified | 225 +---------------------------+OSS/NMS +---------------------------+ 226 | +--------+ | 227 | SFC-enabled Domain A SFC-enabled Domain B | 228 | ---------- ---------- | 229 | // IP/MPLS -\\ //- IP/MPLS -\\ | 230 +----+ // \\ // \\ | 231 |SF- | SN1 SN2 SN3 SN4 SN5 SN6 +-+--+ 232 | |+++--+ +----| +--+++ +++--+ +----+ +--+++-|SF- | 233 |Ingr||SF1 | | | |SF4|| || | |SF7 | | || |Egr | 234 | ++ +------| +----+ +-+ +-----| +-----| +-+ | 235 |ess ||SF2 | | SF3| |SF5 | |SF6 | |SF8 | |SF9 | |ess | 236 +-+-+|+--+-+ +--+-+ +-+--+ +--+-+ +--+-+ +-+--+ |+-+-+ 237 | | | | | | | | | | | | 238 | ||| | ||| ||| | ||| | 239 | | | | | | | | 240 | |\\ | //| |\\ | //| | 241 | | \\- | -// | | \\- | -// | | 242 | | ------+--- | | -----+---- | | 243 L1 | |Ethernet OAM(CC,CV, etc.) | | | 244 o-------D-----------+--------+-------+----------+---------D-------o 245 | | | | | | | | 246 L2 | |IP OAM(Ping, Traceroute, etc.) | | 247 o-------o-----------D--------o-------o----------D---------o-------o 248 | | | | | | | | 249 L3 Transport Independent OAM(Integrated Ethernet with IP OAM | 250 o-------o-----------D--------o-------o----------D---------o-------o 251 | | | | | | | | 252 | | | | | | | | 254 o Maintenance Endpoint(MEP) 255 D Maintenance Intermediary point (MIP) 257 Layer7- SF1 --------------------- SF6 ------- SF7------------- 258 Layer6------------------------F4 -------------------------------- 259 Layer5------------ SF3-------SF5------------------------- SF9---- 260 Layer4---SF2 ---------------------------------- SF8-------------- 262 Figure 2: OAM at Top of Layer 3 264 When the service packet enters into the network, OAM information 265 needs to be imposed by ingress node of the network into the packet 266 (e.g., packet header extension or TLV extension in the overlay 267 header) and pass through the network in the same path as the service 268 traffic and processed by a set of Service Functions that are hosted 269 in Service Nodes and located in different layers at the top of layer 270 3. 272 When any Service Nodes or any service segment between two Service 273 Nodes fails to deliver user traffic, there is a need to provide a 274 tool that would enable users to detect such failures, and a mechanism 275 to isolate faults. 277 In case of several SFs co-located in the same Service Node, the 278 packet is processed by all SFs in the Service Node, Once the packet 279 is successfully handled by one SF, the packet is forwarded to the 280 next SF that is in the same Service Node. 282 When the packet leaves the network, the OAM information needs to be 283 stripped out from the packet. 285 To provide unified view of OAM information common to different layers 286 and different domains, these OAM information needs to gathered from 287 various layer using different encapsulation and tunneling techniques 288 and abstracted and provided to the management application via the 289 unified management interface. 291 As indicated in [I-D.boucadair-sfc-requirements], the following OAM 292 functions are to be supported: 294 o Support means to verify the completion of the forwarding actions 295 until the SFC Border Node is reached (see Section 3.4.1 of 296 [RFC5706]). 298 o Support means to ensure coherent classification rules are 299 installed in and enforced by all the Classifiers of the SFC- 300 enabled domain. 302 o Support means to correlate classification policies with observed 303 forwarding actions. 305 o Support in-band liveliness and functionality checking mechanisms 306 for the instantiated Service Function Chains and the Service 307 Functions that belong to these chains. 309 Other service diagnosis and troubleshooting requirements are 310 discussed in [I-D.boucadair-sfc-requirements]. 312 3.3. Overlay OAM 314 Overlay network is referred to a network that is built on top of 315 another underlying network and provides various services to tenant 316 system. With the growth of network virtualization technology, the 317 needs for inter-connection between various overlay technologies/ 318 networks (e.g., VXLAN or NVGRE) in the Wide Area Network (WAN) become 319 important since it can provide end-to-end connectivity. 321 Domain A Domain B 322 ---------- ---------- 323 //- IP/MPLS -\\ //- IP/MPLS -\\ 324 // \\ // \\ 325 / \ / \ 326 || || || || 327 | | | | 328 +---+ +----+ +----+ +----+ +----+ +----+ +----+ +---+ 329 |CE |--| PE +------| P +----| PE +-+ PE +-----+ P +-----+ PE +--|CE | 330 +-+-+ +--+-+ +--+-+ +-+--+ +--+-+ +--+-+ +-+--+ +-+-+ 331 | | | | | | | | | | | | 332 | ||| | ||| ||| | ||| | 333 | | | | | | | | 334 | |\\ | //| |\\ | //| | 335 | | \\- | -// | | \\- | -// | | 336 | | ------+--- | | -----+---- | | 337 L1 | |Ethernet OAM(CC,CV,etc) | | | 338 o-------D-----------+--------+-------+----------+---------D-------o 339 | | | | | | | | 340 | L2 | |IP OAM(Ping, Traceroute, etc.) | 341 o-----------D--------o-------o----------D---------o- 342 | | | | | | 344 o Maintenance Endpoint(MEP) 345 D Maintenance Intermediary point (MIP) 347 Figure 3: Overlay OAM 349 When a packet traverses a set of overlay networks in the data path, 350 each overlay network will comprise an overlay segment used to connect 351 overlay nodes in the same network and these overlay segment are 352 stitched together to form end to end data path (Figure 3). 354 When any Overlay Segment fails to deliver user traffic, there is a 355 need to provide a tool that would enable users to detect such 356 failures, and a mechanism to isolate faults. It may also be 357 desirable to test the data path before mapping user traffic to the 358 Overlay Segment. 360 4. Requirements 362 This section identifies high-level requirements to fulfill transport 363 independent OAM in Multi-layer Environment to support various use 364 cases discussed in the previous sections. 366 o The interfaces between the management entity and each Managed 367 device in the transport network domain SHOULD support standards- 368 based abstraction with a common information/data model. 370 o The management entity should be able to create a single unified 371 view of OAM information that is common to various layers, various 372 domain and various operators. 374 o The following capability should be supported: 376 * Support customized service diagnostic. 378 * Support diagnose the availability of a end-to-end path. 380 * Support diagnose the availability of a segment Path that is 381 sub-path of end to end path. 383 * Support verification on the correct value of Path ID between 384 any two pair of overlay nodes or any two pair of service nodes. 386 * Support verifying Overlay Control Plane and Data Plane 387 consistency at either two overlay nodes or two service nodes. 389 * Support local diagnostic procedures specific to each Service 390 Node. 392 * Support in-band liveliness and functionality checking 393 mechanisms for the overlay node or service node. 395 * Support Trace on the underlying network. 397 5. IANA Considerations 399 This memo includes no request to IANA. 401 6. Security Considerations 403 TBD. 405 7. References 407 7.1. Normative References 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", March 1997. 412 [TIME-PS] Wu, Q., "Problem Statement and Architecture for Transport- 413 Independent Multiple Layer OAM", ID draft-ww-opsawg-multi- 414 layer-oam-01, June 2014. 416 7.2. Informative References 418 [I-D.boucadair-sfc-requirements] 419 Boucadair, M., Jacquenet, C., Jiang, Y., Parker, R., 420 Pignataro, C., and K. Kengo, "Requirements for Service 421 Function Chaining (SFC)", draft-boucadair-sfc- 422 requirements-05 (work in progress), July 2014. 424 [I-D.ietf-sfc-problem-statement] 425 Quinn, P. and T. Nadeau, "Service Function Chaining 426 Problem Statement", draft-ietf-sfc-problem-statement-07 427 (work in progress), June 2014. 429 [IEEE-802.1Q] 430 IEEE 802.1Q-2011, "IEEE standard for local and 431 metropolitan area networks: Media access control (MAC) 432 bridges and virtual bridged local area networks", August 433 2011. 435 [IEEE-802.1ag] 436 IEEE 802.1ag-2007, "IEEE Standard for Local and 437 Metropolitan Area Networks Virtual Bridged Local Area 438 Networks Amendment 5: Connectivity Fault Management", 439 December 2007. 441 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 442 Management of New Protocols and Protocol Extensions", RFC 443 5706, November 2009. 445 [RFC6291] Andersson, L., Helvoort, H., Bonica, R., Romascanu, D., 446 and S. Mansfield, "Guidelines for the Use of the "OAM" 447 Acronym in the IETF", RFC 6291, June 2011. 449 Authors' Addresses 451 Daniel King 452 Old Dog Consulting 453 UK 455 Email: daniel@olddog.co.uk 457 Mohamed Boucadair 458 France Telecom 459 Rennes 35000 460 France 462 Email: mohamed.boucadair@orange.com 463 Sam Aldrin 464 Huawei Technologies USA 465 2330 Central Expressway 466 NSanta Clara, CA 95051 467 USA 469 Email: aldrin.ietf@gmail.com 471 Greg Mirsky 472 Ericsson 474 Email: gregory.mirsky@ericsson.com 476 Qin Wu 477 Huawei 478 101 Software Avenue, Yuhua District 479 Nanjing, Jiangsu 210012 480 China 482 Email: bill.wu@huawei.com