idnits 2.17.1 draft-ietf-mpls-tp-mip-mep-map-04.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 (November 12, 2012) is 4182 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-mpls-tp-itu-t-identifiers-06 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-tp-security-framework-05 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Farrel 3 Internet-Draft Juniper Networks 4 Intended status: Informational H. Endo 5 Expires: May 16, 2013 Hitachi, Ltd. 6 R. Winter 7 NEC 8 Y. Koike 9 NTT 10 M. Paul 11 Deutsche Telekom 12 November 12, 2012 14 Handling MPLS-TP OAM Packets Targeted at Internal MIPs 15 draft-ietf-mpls-tp-mip-mep-map-04 17 Abstract 19 The Framework for Operations, Administration and Maintenance (OAM) 20 within the MPLS Transport Profile (MPLS-TP) describes how Maintenance 21 Entity Group Intermediate Points (MIPs) may be situated within 22 network nodes at the incoming and outgoing interfaces. 24 This document describes a way of forming OAM messages so that they 25 can be targeted at MIPs on incoming or MIPs on outgoing interfaces, 26 forwarded correctly through the forwarding engine, and handled 27 efficiently in node implementations where there is no distinction 28 between the incoming and outgoing MIP. 30 This document is a product of a joint Internet Engineering Task Force 31 (IETF) / International Telecommunication Union Telecommunication 32 Standardization Sector (ITU-T) effort to include an MPLS Transport 33 Profile within the IETF MPLS and PWE3 architectures to support the 34 capabilities and functionalities of a packet transport network. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on May 16, 2013. 53 Copyright Notice 55 Copyright (c) 2012 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 72 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 4. Summary of the Problem Statement . . . . . . . . . . . . . . . 5 74 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 5.1. Rejected Partial Solution . . . . . . . . . . . . . . . . 10 76 6. Per-Interface MIP Message Handling . . . . . . . . . . . . . . 11 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 85 1. Introduction 87 The Framework for Operations, Administration and Maintenance (OAM) 88 within the MPLS Transport Profile (MPLS-TP)(the MPLS-TP OAM 89 Framework, [RFC6371]) distinguishes two configurations for 90 Maintenance Entity Group Intermediate Points (MIPs) on a node. It 91 defines per-node MIPs and per-interface MIPs, where a per-node MIP is 92 a single MIP per node in an unspecified location within the node and 93 per-interface MIPs are two (or more) MIPs per node on both sides of 94 the forwarding engine. 96 In-band OAM messages are sent using the Generic Associated Channel 97 (G-ACh) [RFC5586]. OAM messages for the transit points of 98 pseudowires (PWs) or Label Switched Paths (LSPs) are delivered using 99 the expiration of the MPLS shim header time-to-live (TTL) field. OAM 100 messages for the end points of PWs and LSPs are simply delivered as 101 normal. 103 OAM messages delivered to end points or transit points are 104 distinguished from other (data) packets so that they can be processed 105 as OAM. In LSPs, the mechanism used is the presence of the Generic 106 Associated Channel Label (GAL) in the Label Stack Entry (LSE) under 107 the top LSE [RFC5586]. In PWs, the mechanism used is the presence of 108 the PW Associated Channel Header (PWACH) [RFC4385] or the presence of 109 a GAL [RFC6423]. 111 In case multiple MIPs are present on a single node, these mechanisms 112 alone provide no way to address one particular MIP out of the set of 113 MIPs. 115 This document describes a way of forming OAM messages so that they 116 can be targeted at incoming MIPs and outgoing MIPs, forwarded 117 correctly through the forwarding engine, and handled efficiently in 118 node implementations where there is no distinction between the 119 incoming and outgoing MIP. 121 This document is a product of a joint Internet Engineering Task Force 122 (IETF)/International Telecommunication Union Telecommunication 123 Standardization Sector (ITU-T) effort to include an MPLS Transport 124 Profile within the IETF MPLS and PWE3 architecture to support the 125 capabilities and functionalities of a packet transport network. 127 Note that the acronym "OAM" is used in conformance with [RFC6291]. 129 2. Requirements notation 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 3. Terminology 137 In this document we use the term in-MIP (incoming MIP) to refer to 138 the MIP which processes OAM messages before they pass through the 139 forwarding engine of a node. An out-MIP (outgoing MIP) processes OAM 140 messages after they have passed the forwarding engine of the node. 141 The two together are referred to as internal MIPs. 143 4. Summary of the Problem Statement 145 Figure 1 shows an abstract functional representation of an MPLS-TP 146 node. It is decomposed as an incoming interface, a forwarding engine 147 (FW), and an outgoing interface. As per the discussion in [RFC6371], 148 MIPs may be placed in each of the functional interface components. 150 ------------------------ 151 |----- -----| 152 | MIP | | MIP | 153 | | ---- | | 154 ----->-| In |->-| FW |->-| Out |->---- 155 | i/f | ---- | i/f | 156 |----- -----| 157 ------------------------ 159 Figure 1: Abstract Functional Representation of an MPLS-TP Node 161 Several distinct OAM functions are required within this architectural 162 model for both PWs and LSPs such as: 164 o CV between a MEP and a MIP 165 o traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing 166 MIPs 167 o data-plane loopback configuration at a MIP 168 o diagnostic tests 170 The MIPs in these OAM functions may equally be the MIPs at the 171 incoming or outgoing interfaces. 173 Per-interface MIPs have the advantage that they enable a more 174 accurate localization and identification of faults and diagnostic 175 test. In particular, the identification of whether a problem is 176 located between nodes or on a particular node and where on that node 177 is greatly enhanced. For obvious reasons, it is important to narrow 178 the cause of a fault down quickly to initiate a timely, and well- 179 directed maintenance action to resume normal network operation. 181 The following two figures illustrate the fundamental difference of 182 using per-node and per-interface MEPs and MIPs for OAM. Figure 2 183 depicts OAM using per-node MIPs and MEPs. For reasons of exposition 184 we pick a location for the MIPs on the nodes but the standard does 185 not mandate the exact location for the per-node model. Figure 3 on 186 the other hand shows the same basic network but for OAM operations 187 per-interface maintenance points are configured. 189 Customer| Operator's administrative | Customer 190 Domain | Domain | Domain 191 ------> |<--------------------------------------->| <------ 192 CE1 | PE1 P1 PE2 | CE2 193 | <--------> <--------> <--------> | 194 +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ 195 | | | | | | | | | | | | | | | | | | | | | | | | 196 | | | | | | | | | | | | | | | | | | | | | | | | 197 +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ 198 | In FW Out In FW Out In FW Out | 199 | | 200 FWD LSP | o-------------------------- > | 201 | V-------------*-------------V | 202 | MEP1 MIP1 MEP2 | 203 BWD LSP | <---------------------------o | 204 | V-------------*-------------V | 205 | MEP1' MIP1' MEP2'| 206 (S1)<============> 207 (S2)<==========================> 209 Figure 2: Example of OAM relying on per-node MIPs and MEPs 211 To illustrate the difference between these two modes of operation, we 212 use fault detection as an example. Consider the case where the 213 client traffic between CE1 and CE2 experiences a fault. Also assume 214 that an on-demand CV test between PE1 and PE2 was successful. The 215 scenario in Figure 2 therefore leaves the forwarding engine (FW) of 216 PE2, the out-going interface of PE2, the transmission line between 217 PE2 and CE2 or CE2 itself as a potential location of the fault as on- 218 demand CV can only be performed on segment S2. 220 The per-interface model in Figure 3 allows more fine-grained OAM 221 operations to be performed. At first, CV on segment S'4 and in 222 addition CV on segment S'5 can help to rule out e.g. the forwarding 223 engine of PE2. This is of course only a single example, and other 224 OAM functions and scenarios are trivially conceivable. The basic 225 message is that with the per-interface OAM model, an operator can 226 configure smaller segments on a transport path to which OAM 227 operations apply. This enables a more fine-grained scoping of OAM 228 operations such as fault localization and performance monitoring 229 which gives operators better information to deal with adverse 230 networking conditions. 232 Customer Operator's administrative Customer 233 Domain Domain Domain 234 ------->|<--------------------------------------->|<------ 235 CE1 | PE1 P1 PE2 | CE2 236 | <--------> <--------> <--------> | 237 +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ 238 | | | | | | | | | | | | | | | | | | | | | | | | 239 | | | | | | | | | | | | | | | | | | | | | | | | 240 +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ 241 | In FW Out In FW Out In FW Out | 242 | | 243 FWD LSP | o-----------------------------------> | 244 | V-------*------*------*-----*-------V | 245 | MEP1 MIP1 MIP2 MIP3 MIP4 MEP2| 246 | | 247 BWD LSP | <-----------------------------------o | 248 | MEP1' MIP1' MIP2' MIP3' MIP4' MEP2'| 249 (S'1)<======> 250 (S'2)<=============> 251 (S'3)<====================> 252 (S'4)<==========================> 253 (S'5)<==================================> 255 Figure 3: Example of OAM relying on per-interface MIPs and MEPs 257 5. Overview 259 In-band OAM messages are sent using the G-ACh [RFC5586] for MPLS-TP 260 LSPs and MPLS-TP PWs, respectively. OAM messages for the transit 261 points of PWs or LSPs are delivered using the expiration of the time- 262 to-live (TTL) field in the top LSE of the MPLS packet header. OAM 263 messages for the end points of PWs and LSPs are simply delivered as 264 normal. 266 OAM messages delivered to end points or transit points are 267 distinguished from other (data) packets so that they can be processed 268 as OAM. In LSPs, the mechanism used is the presence of the Generic 269 Associated Channel Label (GAL) in the LSE under the top LSE 270 [RFC5586]. In PWs, the mechanism used is the presence of the PW 271 Associated Channel Header [RFC4385] or the presence of a GAL 272 [RFC6423]. 274 Any solution for sending OAM messages to the in and out-MIPs must fit 275 within these existing models of handling OAM. 277 Additionally, many MPLS-TP nodes contain an optimization such that 278 all queuing and the forwarding function is performed at the incoming 279 interface. The abstract functional representation of such a node is 280 shown in Figure 4. As shown in the figure, the outgoing interfaces 281 are minimal and for this reason it may not be possible to include MIP 282 functions on those interfaces. This is in particular the case for 283 existing deployed implementations. 285 Any solution that attempts to send OAM messages to the outgoing 286 interface of an MPLS-TP node must not cause any problems when such 287 implementations are present. 289 ------------------ 290 |------------ | 291 | MIP | | 292 | ---- | | 293 ----->-| In | FW | |-->--|->--- 294 | i/f ---- | | 295 |------------ | 296 ------------------ 298 Figure 4: Abstract Functional Representation of an Optimized MPLS-TP 299 Node 301 Lastly, OAM must operate on MPLS-TP nodes that are branch points on 302 point-to-multipoint (P2MP) trees. That means that it must be 303 possible to target individual outgoing MIPs as well as all outgoing 304 MIPs in the abstract functional representation shown in Figure 5, as 305 well as to handle the optimized P2MP node as shown in Figure 6. 307 -------------------------- 308 | -----| 309 | | MIP | 310 | ->-| |->---- 311 | | | Out | 312 | | | i/f | 313 | | -----| 314 |----- | -----| 315 | MIP | ---- | | MIP | 316 | | | |- | | 317 ----->-| In |->-| FW |--->-| Out |->---- 318 | i/f | | |- | i/f | 319 |----- ---- | -----| 320 | | -----| 321 | | | MIP | 322 | | | | 323 | ->-| Out |->---- 324 | | i/f | 325 | -----| 326 -------------------------- 328 Figure 5: Abstract Functional Representation of an MPLS-TP Node 329 Supporting P2MP 331 ------------------ 332 | ->-|->---- 333 | | | 334 |------------ | | 335 | | | | 336 | MIP ---- | | | 337 | | | |- | 338 ----->-| In | FW | |--->-|->---- 339 | i/f | | |- | 340 | ---- | | | 341 | | | | 342 |------------ | | 343 | | | 344 | ->-|->---- 345 ------------------ 347 Figure 6: Abstract Functional Representation of an Optimized MPLS-TP 348 Node Supporting P2MP 350 In summary, the solution for OAM message delivery must support the 351 following features: 353 o Forwarding of OAM packets exactly as data packets. 354 o Delivery of OAM messages to the correct MPLS-TP node. 355 o Delivery of OAM instructions to the correct MIP within an MPLS-TP 356 node. 357 o Packet inspection at the incoming and outgoing interfaces must be 358 minimized. 360 Note that although this issue appears superficially to be an 361 implementation matter local to an individual node, the format of the 362 message needs to be standardised so that: 364 o A MEP can correctly target the outgoing MIP of a specific MPLS-TP 365 node. 366 o A node can correctly filter out any OAM messages that were 367 intended for its upstream neighbor's outgoing MIP, but which were 368 not handled there because the upstream neighbor is an optimized 369 implementation. 371 Note that the last bullet point describes a safety net and an 372 implementation should avoid that this situation ever arises. 374 5.1. Rejected Partial Solution 376 A rejected solution is depicted in Figure 7. All data and non-local 377 OAM is handled as normal. Local OAM is intercepted at the incoming 378 interface and delivered to the MIP at the incoming interface. If the 379 OAM is intended for the incoming MIP it is handled there with no 380 issue. If the OAM is intended for the outgoing MIP it is forwarded 381 to that MIP using some internal messaging system that is 382 implementation-specific. 384 ------------------------ 385 |----- -----| 386 local OAM ----->-| MIP |----->------| MIP | 387 | | ---- | | 388 data =====>=| In |=>=| FW |=>=| Out |=>==== data 389 non-local OAM ~~~~~>~| i/f |~>~| |~>~| i/f |~>~~~~ non-local OAM 390 |----- ---- -----| 391 ------------------------ 393 Figure 7: OAM Control Message Delivery Bypassing the Forwarding 394 Engine 396 This solution is fully functional for the incoming MIP. It also 397 supports control of data loopback for the outgoing MIP, and can 398 adequately perform some OAM features such as interface identity 399 reporting at the outgoing MIP. 401 However, because the OAM message is not forwarded through the 402 forwarding engine, this solution cannot correctly perform OAM 403 loopback, connectivity verification, LSP tracing, or performance 404 measurement. 406 6. Per-Interface MIP Message Handling 408 The preferred solution to per-interface MIP message handling is 409 presented in this section. The appendix of this document contains a 410 few solutions that the authors have discarded which have been left in 411 the document for informational purposes. 413 Per-interface MIP addressing should not require changes to existing 414 OAM solutions. Therefore, identification information that specific 415 OAM mechanisms already contain should be (re-)used to address the 416 MIPs on a node. Upcoming OAM solutions therefore need to 417 individually make sure that enough of that information is present to 418 support the per-interface model. In particular, the MIP identifiers 419 as described in [RFC6370] or [I-D.ietf-mpls-tp-itu-t-identifiers] 420 need to be present in OAM messages. [RFC6370] and 421 [I-D.ietf-mpls-tp-itu-t-identifiers] define formats that support the 422 per-interface model which is sufficient for this purpose. In 423 addition, some constraints must be agreed on. 425 Regarding the features we required earlier from a solution this 426 translates to: 428 o Feature 1: "Forwarding of OAM packets exactly as data packets" 429 * Using existing identification information in OAM messages for 430 internal-MIP addressing has no implications on the way data 431 packets and non-local OAM packets are handled as the label 432 stack is not altered for the purpose of MIP addressing. Also 433 the TTL processing remains untouched. This means that the TTL 434 will expire on the ingress. 435 o Feature 2: "Delivery of OAM messages to the correct MPLS-TP node" 436 * The node itself is addresses using TTL expiry. Therefore, per- 437 interface MIP addressing does not alter node addressing. 438 o Feature 3: "Delivery of OAM instructions to the correct MIP within 439 an MPLS-TP node" 440 * The identification information containted in the OAM packet is 441 used to tell whether the packet is for the in-MIP or the out- 442 MIP. 443 o Feature 4: "Packet inspection at the incoming and outgoing 444 interfaces must be minimized" 445 * Additional packet inspection compared to the per-node case is 446 inevitably needed. The identification information indside the 447 OAM message needs to be considered in order to deliver the 448 packet to the correct MIP. 450 The above illustrates how in principle per-MIP addressing operates. 451 Another issue of concern was the correct filtering of OAM messages at 452 a downstream node, that were intended for an upstream node's outgoing 453 MIP. Since OAM messages expire on the ingress, the legacy upstream 454 neighbor will actually process the packet. Since the identification 455 information is not correct, the node should discard that packet. 456 Leakage should therefore not occur. 458 There might be certain cases where MIP identifiers are not know a 459 priori to other nodes in the network, e.g. in scenarios with static 460 MPLS-TP LSP and PWs. A head end performing route tracing e.g. would 461 have no means to address MIPs in this model. In case OAM solutions 462 expect MIPs to anwser without prior knowledge of the identifier, it 463 is expected that these OAM solutions specify the MIP behaviour in 464 these cases. This could involve unconditional answers from MIPs for 465 certain OAM messages or reserved MIP address for certain OAM tools 466 but the specification of this behaviour is outside the scope of this 467 document. 469 7. Security Considerations 471 OAM security is discussed in [RFC6371] and security aspects specific 472 to MPLS-TP in general are outlined in 473 [I-D.ietf-mpls-tp-security-framework]. 475 OAM can provide useful information for detecting and tracing security 476 attacks. 478 OAM can also be used to illicitly gather information or for denial of 479 service attacks and other types of attack. Implementations therefore 480 are required to offer security mechanisms for OAM. Deployments are 481 strongly advised to use such mechanisms. 483 Mixing of per-node and per-interface OAM on a single node is not 484 advised as OAM message leakage could be the result. 486 8. IANA Considerations 488 This revision of this document does not make any requests of IANA. 490 9. Acknowledgments 492 The authors gratefully acknowledge the substantial contributions of 493 Zhenlong Cui. We would also like to thank Eric Gray and Sami Boutros 494 for interesting input to this document through discussions. 496 10. References 498 10.1. Normative References 500 [I-D.ietf-mpls-tp-itu-t-identifiers] 501 Winter, R., Gray, E., Helvoort, H., and M. Betts, "MPLS-TP 502 Identifiers Following ITU-T Conventions", 503 draft-ietf-mpls-tp-itu-t-identifiers-06 (work in 504 progress), November 2012. 506 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 507 Requirement Levels", BCP 14, RFC 2119, March 1997. 509 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 510 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 511 Use over an MPLS PSN", RFC 4385, February 2006. 513 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 514 Associated Channel", RFC 5586, June 2009. 516 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 517 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 519 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 520 Maintenance Framework for MPLS-Based Transport Networks", 521 RFC 6371, September 2011. 523 [RFC6423] Li, H., Martini, L., He, J., and F. Huang, "Using the 524 Generic Associated Channel Label for Pseudowire in the 525 MPLS Transport Profile (MPLS-TP)", RFC 6423, 526 November 2011. 528 10.2. Informative References 530 [I-D.ietf-mpls-tp-security-framework] 531 Fang, L., Niven-Jenkins, B., Mansfield, S., and R. 532 Graveman, "MPLS-TP Security Framework", 533 draft-ietf-mpls-tp-security-framework-05 (work in 534 progress), October 2012. 536 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 537 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 538 Acronym in the IETF", BCP 161, RFC 6291, June 2011. 540 Authors' Addresses 542 Adrian Farrel 543 Juniper Networks 545 Email: adrian@olddog.co.uk 547 Hideki Endo 548 Hitachi, Ltd. 550 Email: hideki.endo.es@hitachi.com 552 Rolf Winter 553 NEC 555 Email: rolf.winter@neclab.eu 557 Yoshinori Koike 558 NTT 560 Email: koike.yoshinori@lab.ntt.co.jp 562 Manuel Paul 563 Deutsche Telekom 565 Email: Manuel.Paul@telekom.de