idnits 2.17.1 draft-farrel-mpls-tp-mip-mep-map-05.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 (October 31, 2011) is 4554 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-mpls-tp-security-framework-01 Summary: 0 errors (**), 0 flaws (~~), 3 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 Huawei Technologies 4 Intended status: Informational H. Endo 5 Expires: May 3, 2012 Hitachi, Ltd. 6 R. Winter 7 NEC 8 Y. Koike 9 NTT 10 M. Paul 11 Deutsche Telekom 12 October 31, 2011 14 Handling MPLS-TP OAM Packets Targeted at Internal MIPs 15 draft-farrel-mpls-tp-mip-mep-map-05 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 "switch fabric", and handled 27 efficiently in node implementations where there is no distinction 28 between the incoming and outgoing MIP. 30 The material in this document is provided for discussion within the 31 MPLS-TP community in the expectation that this idea or some similar 32 mechanism will be subsumed into a more general MPLS-TP OAM document. 34 This document is a product of a joint Internet Engineering Task Force 35 (IETF) / International Telecommunication Union Telecommunication 36 Standardization Sector (ITU-T) effort to include an MPLS Transport 37 Profile within the IETF MPLS and PWE3 architectures to support the 38 capabilities and functionalities of a packet transport network. 40 Status of this Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on May 3, 2012. 57 Copyright Notice 59 Copyright (c) 2011 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5 76 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 4. Summary of the Problem Statement . . . . . . . . . . . . . . . 5 78 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 5.1. Rejected Partial Solution . . . . . . . . . . . . . . . . 10 80 6. Per-Interface MIP Message Handling . . . . . . . . . . . . . . 11 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 83 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 86 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 87 Appendix A. Previously considered solutions . . . . . . . . . . . 13 88 A.1. GAL TTL . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 A.2. A separate channel type for the out-MIP . . . . . . . . . 13 90 A.3. Decrement TTL once per MIP . . . . . . . . . . . . . . . . 13 91 A.4. Using an ACH reserved bit . . . . . . . . . . . . . . . . 14 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 94 1. Introduction 96 The Framework for Operations, Administration and Maintenance (OAM) 97 within the MPLS Transport Profile (MPLS-TP)(the MPLS-TP OAM 98 Framework, [RFC6371]) distinguishes two configurations for 99 Maintenance Entity Group Intermediate Points (MIPs) on a node. It 100 defines per-node MIPs and per-interface MIPs, where a per-node MIP is 101 a single MIP per node in an unspecified location within the node and 102 per-interface MIPs are two (or more) MIPs per node on both sides of 103 the forwarding engine. 105 In-band OAM messages are sent using the Generic Associated Channel 106 (G-ACh) [RFC5586]. OAM messages for the transit points of 107 pseudowires (PWs) or Label Switched Paths (LSPs) are delivered using 108 the expiration of the MPLS shim header time-to-live (TTL) field. OAM 109 messages for the end points of PWs and LSPs are simply delivered as 110 normal. 112 OAM messages delivered to end points or transit points are 113 distinguished from other (data) packets so that they can be processed 114 as OAM. In LSPs, the mechanism used is the presence of the Generic 115 Associated Channel Label (GAL) in the Label Stack Entry (LSE) under 116 the top LSE [RFC5586]. In PWs, the mechanism used is the presence of 117 the PW Associated Channel Header (PWACH) [RFC4385]. 119 In case multiple MIPs are present on a single node, these mechanisms 120 alone provide no way to address one particular MIP out of the set of 121 MIPs. 123 This document describes a way of forming OAM messages so that they 124 can be targeted at incoming MIPs and outgoing MIPs, forwarded 125 correctly through the "switch fabric", and handled efficiently in 126 node implementations where there is no distinction between the 127 incoming and outgoing MIP. 129 The material in this document is provided for discussion within the 130 MPLS-TP community in the expectation that this idea or some similar 131 mechanisms will be subsumed into a more general MPLS-TP OAM document. 133 This document is a product of a joint Internet Engineering Task Force 134 (IETF)/International Telecommunication Union Telecommunication 135 Standardization Sector (ITU-T) effort to include an MPLS Transport 136 Profile within the IETF MPLS and PWE3 architecture to support the 137 capabilities and functionalities of a packet transport network. 139 Note that the acronym "OAM" is used in conformance with [RFC6291]. 141 2. Requirements notation 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 3. Terminology 149 In this document we use the term in-MIP (incoming MIP) to refer to 150 the MIP which processes OAM messages before they pass through the 151 forwarding engine of a node. An out-MIP (outgoing MIP) processes OAM 152 messages after they have passed the forwarding engine of the node. 153 The two together are referred to as internal MIPs. 155 4. Summary of the Problem Statement 157 Figure 1 shows an abstract functional representation of an MPLS-TP 158 node. It is decomposed as an incoming interface, a cross-connect 159 (XC), and an outgoing interface. As per the discussion in [RFC6371], 160 MIPs may be placed in each of the functional interface components. 162 ------------------------ 163 |----- -----| 164 | MIP | | MIP | 165 | | ---- | | 166 ----->-| In |->-| XC |->-| Out |->---- 167 | i/f | ---- | i/f | 168 |----- -----| 169 ------------------------ 171 Figure 1: Abstract Functional Representation of an MPLS-TP Node 173 Several distinct OAM functions are required within this architectural 174 model such as: 176 o CV between a MEP and a MIP 177 o traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing 178 MIPs 179 o OAM control at a MIP 180 o data-plane loopback at a MIP 181 o diagnostic tests 183 The MIPs in these OAM functions may equally be the MIPs at the 184 incoming or outgoing interfaces. 186 Per-interface MIPs have the advantage that they enable a more 187 accurate localization and identification of faults and targeted 188 performance monitoring or diagnostic test. In particular, the 189 identification of whether a problem is located between nodes or on a 190 particular node and where on that node is greatly enhanced. For 191 obvious reasons, it is important to narrow the cause of a fault down 192 quickly to initiate a timely, and well-directed maintenance action to 193 resume normal network operation. 195 The following two figures illustrate the fundamental difference of 196 using per-node and per-interface MEPs and MIPs for OAM. Figure 2 197 depicts OAM using per-node MIPs and MEPs. For reasons of exposition 198 we pick a location for the MIPs on the nodes but the standard does 199 not mandate the exact location for the per-node model. Figure 3 on 200 the other hand shows the same basic network but for OAM operations 201 per-interface maintenance points are configured. 203 Customer| Operator's administrative | Customer 204 Domain | Domain | Domain 205 ------> |<--------------------------------------->| <------ 206 CE1 | PE1 P1 PE2 | CE2 207 | <--------> <--------> <--------> | 208 +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ 209 | | | | | | | | | | | | | | | | | | | | | | | | 210 | | | | | | | | | | | | | | | | | | | | | | | | 211 +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ 212 | In FW Out In FW Out In FW Out | 213 | | 214 FWD LSP | o-------------------------- > | 215 | V-------------*-------------V | 216 | MEP1 MIP1 MEP2 | 217 BWD LSP | <---------------------------o | 218 | V-------------*-------------V | 219 | MEP1' MIP1' MEP2'| 220 (S1)<============> 221 (S2)<==========================> 223 Figure 2: Example of OAM relying on per-node MIPs and MEPs 225 To illustrate the difference between these two modes of operation, we 226 use fault detection as an example. Consider the case where the 227 client traffic between CE1 and CE2 experiences a fault. Also assume 228 that an on-demand CV test between PE1 and PE2 was successful. The 229 scenario in Figure 2 therefore leaves the forwarding engine(FW) of 230 PE2, the out-going interface of PE2, the transmission line between 231 PE2 and CE2 or CE2 itself as a potential location of the fault as on- 232 demand CV can only be performed on segment S2. 234 The per-interface model in Figure 3 allows more fine-grained OAM 235 operations to be performed. At first, CV on segment S'4 and in 236 addition CV on segment S'5 can help to rule out e.g. the forwarding 237 engine of PE2. This is of course only a single example, and other 238 OAM functions and scenarios are trivially conceivable. The basic 239 message is that with the per-interface OAM model, an operator can 240 configure smaller segments on a transport path to which OAM 241 operations apply. This enables a more fine-grained scoping of OAM 242 operations such as fault localization and performance monitoring 243 which gives operators better information to deal with adverse 244 networking conditions. 246 Customer Operator's administrative Customer 247 Domain Domain Domain 248 ------->|<--------------------------------------->|<------ 249 CE1 | PE1 P1 PE2 | CE2 250 | <--------> <--------> <--------> | 251 +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ 252 | | | | | | | | | | | | | | | | | | | | | | | | 253 | | | | | | | | | | | | | | | | | | | | | | | | 254 +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ 255 | In FW Out In FW Out In FW Out | 256 | | 257 FWD LSP | o-----------------------------------> | 258 | V-------*------*------*-----*-------V | 259 | MEP1 MIP1 MIP2 MIP3 MIP4 MEP2| 260 | | 261 BWD LSP | <-----------------------------------o | 262 | MEP1' MIP1' MIP2' MIP3' MIP4' MEP2'| 263 (S'1)<======> 264 (S'2)<=============> 265 (S'3)<====================> 266 (S'4)<==========================> 267 (S'5)<==================================> 269 Figure 3: Example of OAM relying on per-interface MIPs and MEPs 271 5. Overview 273 In-band OAM messages are sent using the G-ACh [RFC5586] for MPLS-TP 274 LSPs and MPLS-TP PWs, respectively. OAM messages for the transit 275 points of PWs or LSPs are delivered using the expiration of the time- 276 to-live (TTL) field in the top LSE of the MPLS packet header. OAM 277 messages for the end points of PWs and LSPs are simply delivered as 278 normal. 280 OAM messages delivered to end points or transit points are 281 distinguished from other (data) packets so that they can be processed 282 as OAM. In LSPs, the mechanism used is the presence of the Generic 283 Associated Channel Label (GAL) in the LSE under the top LSE 284 [RFC5586]. In PWs, the mechanism used is the presence of the PW 285 Associated Channel Header [RFC4385]. 287 Any solution for sending OAM to the in and out-MIPs must fit within 288 these existing models of handling OAM. 290 Additionally, many MPLS-TP nodes contain an optimization such that 291 all queuing and the forwarding function is performed at the incoming 292 interface. The abstract functional representation of such a node is 293 shown in Figure 4. As shown in the figure, the outgoing interfaces 294 are minimal and for this reason it may not be possible to include MIP 295 functions on those interfaces. This is in particular the case for 296 existing deployed implementations. 298 Any solution that attempts to send OAM to the outgoing interface of 299 an MPLS-TP node must not cause any problems when such implementations 300 are present. 302 ------------------ 303 |------------ | 304 | MIP | | 305 | ---- | | 306 ----->-| In | XC | |-->--|->--- 307 | i/f ---- | | 308 |------------ | 309 ------------------ 311 Figure 4: Abstract Functional Representation of an Optimized MPLS-TP 312 Node 314 Lastly, OAM must operate on MPLS-TP nodes that are branch points on 315 point-to-multipoint (P2MP) trees. That means that it must be 316 possible to target individual outgoing MIPs as well as all outgoing 317 MIPs in the abstract functional representation shown in Figure 5, as 318 well as to handle the optimized P2MP node as shown in Figure 6. 320 -------------------------- 321 | -----| 322 | | MIP | 323 | ->-| |->---- 324 | | | Out | 325 | | | i/f | 326 | | -----| 327 |----- | -----| 328 | MIP | ---- | | MIP | 329 | | | |- | | 330 ----->-| In |->-| XC |--->-| Out |->---- 331 | i/f | | |- | i/f | 332 |----- ---- | -----| 333 | | -----| 334 | | | MIP | 335 | | | | 336 | ->-| Out |->---- 337 | | i/f | 338 | -----| 339 -------------------------- 341 Figure 5: Abstract Functional Representation of an MPLS-TP Node 342 Supporting P2MP 344 ------------------ 345 | ->-|->---- 346 | | | 347 |------------ | | 348 | | | | 349 | MIP ---- | | | 350 | | | |- | 351 ----->-| In | XC | |--->-|->---- 352 | i/f | | |- | 353 | ---- | | | 354 | | | | 355 |------------ | | 356 | | | 357 | ->-|->---- 358 ------------------ 360 Figure 6: Abstract Functional Representation of an Optimized MPLS-TP 361 Node Supporting P2MP 363 In summary, the solution for OAM message delivery must support the 364 following features: 366 o Forwarding of OAM packets exactly as data packets. 367 o Delivery of OAM messages to the correct MPLS-TP node. 368 o Delivery of OAM instructions to the correct MIP within an MPLS-TP 369 node. 370 o Packet inspection at the incoming and outgoing interfaces must be 371 minimized. 373 Note that although this issue appears superficially to be an 374 implementation matter local to an individual node, the format of the 375 message needs to be standardised so that: 377 o A MEP can correctly target the outgoing MIP of a specific MPLS-TP 378 node. 379 o A node can correctly filter out any OAM messages that were 380 intended for its upstream neighbor's outgoing MIP, but which were 381 not handled there because the upstream neighbor is an optimized 382 implementation. 384 Note that the last bullet point describes a safety net and an 385 implementation should avoid that this situation ever arises. 387 5.1. Rejected Partial Solution 389 A rejected solution is depicted in Figure 7. All data and non-local 390 OAM is handled as normal. Local OAM is intercepted at the incoming 391 interface and delivered to the MIP at the incoming interface. If the 392 OAM is intended for the incoming MIP it is handled there with no 393 issue. If the OAM is intended for the outgoing MIP it is forwarded 394 to that MIP using some internal messaging system that is 395 implementation-specific. 397 ------------------------ 398 |----- -----| 399 local OAM ----->-| MIP |----->------| MIP | 400 | | ---- | | 401 data =====>=| In |=>=| XC |=>=| Out |=>==== data 402 non-local OAM ~~~~~>~| i/f |~>~| |~>~| i/f |~>~~~~ non-local OAM 403 |----- ---- -----| 404 ------------------------ 406 Figure 7: OAM Control Message Delivery Bypassing the Switching Fabric 408 This solution is fully functional for the incoming MIP. It also 409 supports control of data loopback for the outgoing MIP, and can 410 adequately perform some OAM features such as interface identity 411 reporting at the outgoing MIP. 413 However, because the OAM message is not forwarded through the switch 414 fabric, this solution cannot correctly perform OAM loopback, 415 connectivity verification, LSP tracing, or performance measurement. 417 6. Per-Interface MIP Message Handling 419 The preferred solution to per-interface MIP message handling is 420 presented in this section. The appendix of this document contains a 421 few solutions that the authors have discarded which have been left in 422 the document for informational purposes. 424 Per-interface MIP addressing should not require changes to existing 425 OAM solutions. Therefore, ID information that specific OAM 426 mechanisms already contain should be (re-)used to address the MIPs on 427 a node. Upcoming OAM solutions therefore need to individually make 428 sure that enough of that information is present to support the per- 429 interface model. In particular, the MIP identifiers as described in 430 [RFC6370] need to be present in OAM messages. [RFC6370] defines a 431 format that supports the per-interface model which is sufficient for 432 this purpose. In addition, some constraints must be agreed on. 434 Regarding the features we required earlier from a solution this 435 translates to: 437 o Feature 1: "Forwarding of OAM packets exactly as data packets" 438 * This way of internal-MIP addressing has no implications on the 439 way data packets and non-local OAM packets are handled as the 440 label stack is not altered for the purpose of MIP addressing. 441 Also the TTL processing remains untouched. This means that the 442 TTL will expire on the ingress. 443 o Feature 2: "Delivery of OAM messages to the correct MPLS-TP node" 444 * The node itself is addresses using TTL expiry, comparable to 445 the per-node MIP addressing case. 446 o Feature 3: "Delivery of OAM instructions to the correct MIP within 447 an MPLS-TP node" 448 * The ID information containted in the OAM packet is used to tell 449 whether the packet is for the in or out-MIP. 450 o Feature 4: "Packet inspection at the incoming and outgoing 451 interfaces must be minimized" 452 * Additional packet inspection compared to the per-node case is 453 inevitably needed. The ID information indside the OAM message 454 needs to be considered in order to deliver the packet to the 455 right MIP. 457 The above illustrates how in principle per-MIP addressing operates. 458 Another issue of concern was the correct filtering of OAM messages at 459 a downstream node, that were intended for an upstream node's outgoing 460 MIP. Since OAM messages expire on the ingress, the legacy upstream 461 neighbor will actually process the packet. Since the ID information 462 is not correct, the node should discard that packet. Leakage should 463 therefore not occur. 465 7. Security Considerations 467 OAM security is discussed in [RFC6371] and security aspects specific 468 to MPLS-TP in general are outlined in 469 [I-D.ietf-mpls-tp-security-framework]. 471 OAM can provide useful information for detecting and tracing security 472 attacks. 474 OAM can also be used to illicitly gather information or for denial of 475 service attacks and other types of attack. Implementations therefore 476 are required to offer security mechanisms for OAM. Deployments are 477 strongly advised to use such mechanisms. 479 Mixing of per-node and per-interface OAM on a single node is not 480 advised as OAM message leakage could be the result. 482 8. IANA Considerations 484 This revision of this document does not make any requests of IANA. 486 9. Acknowledgments 488 The authors gratefully acknowledge the substantial contributions of 489 Zhenlong Cui. We would also like to thank Eric Gray and Sami Boutros 490 for interesting input to this document through discussions. 492 10. References 494 10.1. Normative References 496 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 497 Requirement Levels", BCP 14, RFC 2119, March 1997. 499 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 500 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 501 Use over an MPLS PSN", RFC 4385, February 2006. 503 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 504 Associated Channel", RFC 5586, June 2009. 506 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 507 Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 509 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 510 Maintenance Framework for MPLS-Based Transport Networks", 511 RFC 6371, September 2011. 513 10.2. Informative References 515 [I-D.ietf-mpls-tp-security-framework] 516 Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP 517 Security Framework", 518 draft-ietf-mpls-tp-security-framework-01 (work in 519 progress), May 2011. 521 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 522 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 523 Acronym in the IETF", BCP 161, RFC 6291, June 2011. 525 Appendix A. Previously considered solutions 527 A.1. GAL TTL 529 The use of the GAL TTL has been considered before. This transforms 530 the GAL TTL into some kind of node-internal TTL, i.e. a GAL TTL of 0 531 would address the in-MIP and a GAL TTL of 1 the out-MIP. The main 532 drawback of this approach is that it (as of now at least) would only 533 be applicable to LSPs and not to PWs. 535 A.2. A separate channel type for the out-MIP 537 This approach would require two channel types for the exact same OAM 538 type, one to address the in-MIP and another one to address the out- 539 MIP. This seems like a waste of channel types, however it appears 540 that there is no expected shortage of them. Legacy nodes will 541 discard the packets as the new channel types are unkonwn. Having two 542 channel types for the same OAM however feels a bit hacky. 544 A.3. Decrement TTL once per MIP 546 Decrementing the TTL more than once per node seems a "natural" way of 547 per-interface MIP addressing since TTL expiry is all that is needed 548 for the per-node MIP case. In other words, by decrementing the TTL 549 once per MIP (twice per node) no extra mechanism is needed to solve 550 the internal MIP addressing problem. The solution has been discarded 551 since it does not represent the typical mode of network operation 552 today (since also for normal data packets the TTL needs to be 553 decremented more than once). 555 A.4. Using an ACH reserved bit 557 The ACH contains eight reserved bits which currently all need to be 558 set to zero and ignored on reception. One bit could be reserved as 559 an out-MIP address flag. In other words, in case the bit is set, the 560 out-MIP is addressed. An advantage of this approach is that there is 561 no semantic overlap with anything that exists today, as the bits are 562 not in use. Existing implementations need to ignore it. That means 563 that existing implementations will process the OAM packets at the in- 564 MIP/per-node MIP. ID information is still needed however for the 565 P2MP case as a single bit is not enough. 567 Authors' Addresses 569 Adrian Farrel 570 Huawei Technologies 572 Email: adrian.farrel@huawei.com 574 Hideki Endo 575 Hitachi, Ltd. 577 Email: hideki.endo.es@hitachi.com 579 Rolf Winter 580 NEC 582 Email: rolf.winter@neclab.eu 584 Yoshinori Koike 585 NTT 587 Email: koike.yoshinori@lab.ntt.co.jp 589 Manuel Paul 590 Deutsche Telekom 592 Email: Manuel.Paul@telekom.de