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