idnits 2.17.1 draft-ietf-mpls-tp-mip-mep-map-08.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 31, 2013) is 3920 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: February 1, 2014 Hitachi, Ltd. 6 R. Winter 7 NEC 8 Y. Koike 9 NTT 10 M. Paul 11 Deutsche Telekom 12 July 31, 2013 14 Per-Interface MIP Addressing Requirements and Design Considerations 15 draft-ietf-mpls-tp-mip-mep-map-08 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 elaborates on important considerations for internal MIP 25 addressing. More precisely it describes important restrictions for 26 any mechanism that specifies a way of forming OAM messages so that 27 they can be targeted at MIPs on incoming or MIPs on outgoing 28 interfaces and forwarded correctly through the forwarding engine. 29 Furthermore, the document includes considerations for node 30 implementations where there is no distinction between the incoming 31 and outgoing MIP. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on February 1, 2014. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 4. Summary of the Problem Statement . . . . . . . . . . . . . . . 4 71 5. Requirements and Design Considerations for Internal-MIP 72 Adressing . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 The Framework for Operations, Administration and Maintenance (OAM) 84 within the MPLS Transport Profile (MPLS-TP)(the MPLS-TP OAM 85 Framework, [RFC6371]) distinguishes two configurations for 86 Maintenance Entity Group Intermediate Points (MIPs) on a node. It 87 defines per-node MIPs and per-interface MIPs, where a per-node MIP is 88 a single MIP per node in an unspecified location within the node and 89 per-interface MIPs are two (or more) MIPs per node on each side of 90 the forwarding engine. 92 In-band OAM messages are sent using the Generic Associated Channel 93 (G-ACh) [RFC5586]. OAM messages for the transit points of 94 pseudowires (PWs) or Label Switched Paths (LSPs) are delivered using 95 the expiration of the MPLS shim header time-to-live (TTL) field. OAM 96 messages for the end points of PWs and LSPs are simply delivered as 97 normal. 99 OAM messages delivered to end points or transit points are 100 distinguished from other (data) packets so that they can be processed 101 as OAM. In LSPs, the mechanism used is the presence of the Generic 102 Associated Channel Label (GAL) in the Label Stack Entry (LSE) under 103 the top LSE [RFC5586]. In PWs, the mechanism used is the presence of 104 the PW Associated Channel Header (PWACH) [RFC4385] or the presence of 105 a GAL [RFC6423]. 107 In case multiple MIPs are present on a single node, these mechanisms 108 alone provide no way to address one particular MIP out of the set of 109 MIPs. A mechanism that addresses this shortcoming has to obey a few 110 important design considerations which are discussed in this document. 112 Note that the acronym "OAM" is used in conformance with [RFC6291]. 114 2. Requirements notation 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 3. Terminology 122 In this document we use the term in-MIP (incoming MIP) to refer to 123 the MIP which processes OAM messages before they pass through the 124 forwarding engine of a node. An out-MIP (outgoing MIP) processes OAM 125 messages after they have passed the forwarding engine of the node. 126 The two together are referred to as internal MIPs. 128 4. Summary of the Problem Statement 130 Figure 1 shows an abstract functional representation of an MPLS-TP 131 node. It is decomposed as an incoming interface, a forwarding engine 132 (FW), and an outgoing interface. As per the discussion in [RFC6371], 133 MIPs may be placed in each of the functional interface components. 135 ------------------------ 136 |----- -----| 137 | MIP | | MIP | 138 | | ---- | | 139 ----->-| In |->-| FW |->-| Out |->---- 140 | i/f | ---- | i/f | 141 |----- -----| 142 ------------------------ 144 Figure 1: Abstract Functional Representation of an MPLS-TP Node 146 Several distinct OAM functions are required within this architectural 147 model for both PWs and LSPs such as: 149 o Connectivity Verification (CV) between a MEP and a MIP 150 o traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing 151 MIPs 152 o data-plane loopback configuration at a MIP 153 o diagnostic tests 155 The MIPs in these OAM functions may equally be the MIPs at the 156 incoming or outgoing interfaces. 158 Per-interface MIPs have the advantage that they enable a more 159 accurate localization and identification of faults and diagnostic 160 tests. In particular, the identification of whether a problem is 161 located between nodes or on a particular node and where on that node 162 is greatly enhanced. For obvious reasons, it is important to narrow 163 the cause of a fault down quickly to initiate a timely, and well- 164 directed maintenance action to resume normal network operation. 166 The following two figures illustrate the fundamental difference of 167 using per-node and per-interface MEPs and MIPs for OAM. Figure 2 168 depicts OAM using per-node MIPs and MEPs. For reasons of exposition 169 we pick a location for the MIPs on the nodes but the standard does 170 not mandate the exact location for the per-node model. In the figure 171 a bi-directional LSP is depicted where in the forward (FWD) direction 172 MEP1, MIP1, and MEP2 are located on the ingress interface (IF). In 173 the backward (BWD) direction MEP1', MIP1' and MEP2' are located on 174 the egress IF, i.e. the same interfaces. S1 in the figure denotes 175 the segment from PE1 In to P1 In and S2 denotes the segment from PE1 176 In to P2 In. Figure 3 on the other hand shows the same basic network 177 but for OAM operations per-interface maintenance points are 178 configured. Note that these figures are merely examples. It is 179 important to note that per-interface MEPs or per-interface MIPs MUST 180 logically be placed at a point before (for in-MIP) or after (for out- 181 MIP) passing the forwarding engine as defined in [RFC6371]. It MUST 182 be assured that all traffic for which the MEP/MIP is associated with 183 must pass through or be terminated at that point. 185 Customer| Operator's administrative | Customer 186 Domain | Domain | Domain 187 ------> |<--------------------------------------->| <------ 188 CE1 | T-PE/PE1 S-PE/P1 T-PE/PE2 | CE2 189 | <--------> <--------> <--------> | 190 +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ 191 | | | | | | | | | | | | | | | | | | | | | | | | 192 | | | | | | | | | | | | | | | | | | | | | | | | 193 +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ 194 | In FW Out In FW Out In FW Out | 195 | | 196 FWD PW/LSP | o-------------------------- > | 197 | V-------------*-------------V | 198 | MEP1 MIP1 MEP2 | 199 BWD PW/LSP | <---------------------------o | 200 | V-------------*-------------V | 201 | MEP1' MIP1' MEP2'| 202 (S1)<============> 203 (S2)<==========================> 205 Figure 2: Example of OAM relying on per-node MIPs and MEPs 207 To illustrate the difference between these two modes of operation, we 208 use fault detection as an example. Consider the case where the 209 client traffic between CE1 and CE2 experiences a fault. Also assume 210 that an on-demand CV test between PE1 and PE2 was successful. The 211 scenario in Figure 2 therefore leaves the forwarding engine (FW) of 212 PE2, the out-going interface of PE2, the transmission line between 213 PE2 and CE2 or CE2 itself as a potential location of the fault as on- 214 demand CV can only be performed on segment S2. Note that in this 215 scenario, the PWs or LSPs are to be understood as two examples (not 216 one). I.e. the figures do not show the layer structure of PWs and 217 LSPs. 219 The per-interface model in Figure 3 allows more fine-grained OAM 220 operations to be performed. At first, CV on segment S'4 and in 221 addition CV on segment S'5 can help to rule out e.g. the forwarding 222 engine of PE2. This is of course only a single example, and other 223 OAM functions and scenarios are trivially conceivable. The basic 224 message is that with the per-interface OAM model, an operator can 225 configure smaller segments on a transport path to which OAM 226 operations apply. This enables a more fine-grained scoping of OAM 227 operations such as fault localization and performance monitoring 228 which gives operators better information to deal with adverse 229 networking conditions. 231 Customer Operator's administrative Customer 232 Domain Domain Domain 233 ------->|<--------------------------------------->|<------ 234 CE1 | T-PE/PE1 S-PE/P1 T-PE/PE2 | CE2 235 | <--------> <--------> <--------> | 236 +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ 237 | | | | | | | | | | | | | | | | | | | | | | | | 238 | | | | | | | | | | | | | | | | | | | | | | | | 239 +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ 240 | In FW Out In FW Out In FW Out | 241 | | 242 FWD PW/LSP | o-----------------------------------> | 243 | V-------*------*------*-----*-------V | 244 | MEP1 MIP1 MIP2 MIP3 MIP4 MEP2| 245 | | 246 BWD PW/LSP | <-----------------------------------o | 247 | MEP1' MIP1' MIP2' MIP3' MIP4' MEP2'| 248 (S'1)<======> 249 (S'2)<=============> 250 (S'3)<====================> 251 (S'4)<==========================> 252 (S'5)<==================================> 254 Figure 3: Example of OAM relying on per-interface MIPs and MEPs 256 5. Requirements and Design Considerations for Internal-MIP Adressing 258 OAM messages for transit points of PWs or LSPs are delivered using 259 the expiration of the time-to-live (TTL) field in the top LSE of the 260 MPLS packet header. OAM messages for the end points of PWs and LSPs 261 are simply delivered as normal. These messages are distinguished 262 from other (data) packets so that they can be processed as OAM. In 263 LSPs, the mechanism used is the presence of the Generic Associated 264 Channel Label (GAL) in the LSE under the top LSE [RFC5586]. In PWs, 265 the mechanism used is the presence of the PW Associated Channel 266 Header [RFC4385] or the presence of a GAL [RFC6423]. In addition, 267 two sets of identifiers exist that can be used to address MIPs which 268 are defined in [RFC6370] and [I-D.ietf-mpls-tp-itu-t-identifiers] 270 Any solution for sending OAM messages to the in and out-MIPs must fit 271 within these existing models of handling OAM. 273 Additionally, many MPLS-TP nodes are implemented in a way that all 274 queuing and the forwarding function is performed at the incoming 275 interface. The abstract functional representation of such a node is 276 shown in Figure 4. As shown in the figure, the outgoing interfaces 277 are minimal and for this reason it may not be possible to include MIP 278 functions on those interfaces. This is in particular the case for 279 existing deployed implementations. 281 Any solution that attempts to send OAM messages to the outgoing 282 interface of an MPLS-TP node must not cause any problems when such 283 implementations are present (such as leaking OAM packets with a TTL 284 of 0). 286 --------------------- 287 |------------ | 288 | MIP | | 289 | ---- | | 290 ----->-| In | FW | |-->-Out-|->--- 291 | i/f ---- | i/f | 292 |------------ | 293 --------------------- 295 Figure 4: Abstract Functional Representation of Some Existing MPLS-TP 296 Nodes 298 OAM must operate on MPLS-TP nodes that are branch points on point-to- 299 multipoint (P2MP) trees. That means that it must be possible to 300 target individual outgoing MIPs as well as all outgoing MIPs in the 301 abstract functional representation shown in Figure 5, as well as to 302 handle the P2MP node implementations as shown in Figure 6 without 303 causing problems. 305 -------------------------- 306 | -----| 307 | | MIP | 308 | ->-| |->---- 309 | | | Out | 310 | | | i/f | 311 | | -----| 312 |----- | -----| 313 | MIP | ---- | | MIP | 314 | | | |- | | 315 ----->-| In |->-| FW |--->-| Out |->---- 316 | i/f | | |- | i/f | 317 |----- ---- | -----| 318 | | -----| 319 | | | MIP | 320 | | | | 321 | ->-| Out |->---- 322 | | i/f | 323 | -----| 324 -------------------------- 326 Figure 5: Abstract Functional Representation of an MPLS-TP Node 327 Supporting P2MP 329 ---------------------- 330 | ->-Out-|->---- 331 | | i/f | 332 |------------ | | 333 | | | | 334 | MIP ---- | | | 335 | | | |- | 336 ----->-| In | FW | |--->-Out-|->---- 337 | i/f | | |- i/f | 338 | ---- | | | 339 | | | | 340 |------------ | | 341 | | Out | 342 | ->-i/f-|->---- 343 ---------------------- 345 Figure 6: Abstract Functional Representation of Some Existing MPLS-TP 346 Nodes Supporting P2MP 348 In summary, the solution for OAM message delivery must behave as 349 follows: 351 o Delivery of OAM messages to the correct MPLS-TP node. 352 o Delivery of OAM instructions to the correct MIP within an MPLS-TP 353 node. 354 o Forwarding of OAM packets exactly as data packets. 355 o Packet inspection at the incoming and outgoing interfaces must be 356 minimized. 358 The first and second bullet point are obvious. The third bullet 359 point however is also vital. To illustrate the importance, a 360 rejected solution is depicted in Figure 7. In the figure, all data 361 and non-local OAM is handled as normal. Local OAM is intercepted at 362 the incoming interface and delivered to the MIP at the incoming 363 interface. If the OAM is intended for the incoming MIP it is handled 364 there with no issue. If the OAM is intended for the outgoing MIP it 365 is forwarded to that MIP using some internal messaging system that is 366 implementation-specific. 368 ------------------------ 369 |----- -----| 370 local OAM ----->-| MIP |----->------| MIP | 371 | | ---- | | 372 data =====>=| In |=>=| FW |=>=| Out |=>==== data 373 non-local OAM ~~~~~>~| i/f |~>~| |~>~| i/f |~>~~~~ non-local OAM 374 |----- ---- -----| 375 ------------------------ 377 Figure 7: OAM Control Message Delivery Bypassing the Forwarding 378 Engine 380 This solution is fully functional for the incoming MIP. It also 381 supports control of data loopback for the outgoing MIP, and can 382 adequately perform some OAM features such as interface identity 383 reporting at the outgoing MIP. 385 However, because the OAM message is not forwarded through the 386 forwarding engine, this solution cannot correctly perform OAM 387 loopback, connectivity verification, LSP tracing, or performance 388 measurement. 390 The last bullet point is also an important requirement for any 391 solution to the internal-MIP addressing problem. Since OAM packets 392 that target an out-MIP need to be sent through the forwarding engine 393 and treated exactly as regular data packets, the determination of 394 whether to forward the packet or process it at the incoming MIP needs 395 to be fast and therefore the processing overhead must be kept to a 396 minimum. In addition, there are a few OAM procedures that operate at 397 line rate such as OAM loopback. This adds to the requirement of 398 minimal processing overhead for both the in-MIP and out-MIP. 400 Most of the above superficially appears to be an implementation 401 matter local to an individual node, the format of the message needs 402 to be standardised so that: 404 o A MEP can correctly target the outgoing MIP of a specific MPLS-TP 405 node. 406 o A node can correctly filter out any OAM messages that were 407 intended for its upstream neighbor's outgoing MIP, but which were 408 not handled there because the upstream neighbor is an 409 implementation as shown in Figure 4 or Figure 6. 411 Note that the last bullet point describes a safety net and an 412 implementation should avoid that this situation ever arises. 414 6. Security Considerations 416 OAM security is discussed in [RFC6371] and security aspects specific 417 to MPLS-TP in general are outlined in 418 [I-D.ietf-mpls-tp-security-framework]. 420 OAM can provide useful information for detecting and tracing security 421 attacks. 423 OAM can also be used to illicitly gather information or for denial of 424 service attacks and other types of attack. Implementations therefore 425 are required to offer security mechanisms for OAM. Deployments are 426 strongly advised to use such mechanisms. 428 Mixing of per-node and per-interface OAM on a single node is not 429 advised as OAM message leakage could be the result. 431 7. IANA Considerations 433 This revision of this document does not make any requests of IANA. 435 8. Acknowledgments 437 The authors gratefully acknowledge the substantial contributions of 438 Zhenlong Cui. We would also like to thank Eric Gray, Sami Boutros and 439 Shahram Davari for interesting input to this document through 440 discussions. 442 9. References 444 9.1. Normative References 446 [I-D.ietf-mpls-tp-itu-t-identifiers] 447 Winter, R., Gray, E., Helvoort, H., and M. Betts, "MPLS-TP 448 Identifiers Following ITU-T Conventions", 449 draft-ietf-mpls-tp-itu-t-identifiers-08 (work in 450 progress), February 2013. 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, March 1997. 455 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 456 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 457 Use over an MPLS PSN", RFC 4385, February 2006. 459 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 460 Associated Channel", RFC 5586, June 2009. 462 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 463 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 465 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 466 Maintenance Framework for MPLS-Based Transport Networks", 467 RFC 6371, September 2011. 469 [RFC6423] Li, H., Martini, L., He, J., and F. Huang, "Using the 470 Generic Associated Channel Label for Pseudowire in the 471 MPLS Transport Profile (MPLS-TP)", RFC 6423, 472 November 2011. 474 9.2. Informative References 476 [I-D.ietf-mpls-tp-security-framework] 477 Fang, L., Niven-Jenkins, B., Mansfield, S., and R. 478 Graveman, "MPLS-TP Security Framework", 479 draft-ietf-mpls-tp-security-framework-09 (work in 480 progress), February 2013. 482 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 483 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 484 Acronym in the IETF", BCP 161, RFC 6291, June 2011. 486 Authors' Addresses 488 Adrian Farrel 489 Juniper Networks 491 Email: adrian@olddog.co.uk 493 Hideki Endo 494 Hitachi, Ltd. 496 Email: hideki.endo.es@hitachi.com 498 Rolf Winter 499 NEC 501 Email: rolf.winter@neclab.eu 503 Yoshinori Koike 504 NTT 506 Email: koike.yoshinori@lab.ntt.co.jp 508 Manuel Paul 509 Deutsche Telekom 511 Email: Manuel.Paul@telekom.de