idnits 2.17.1 draft-ietf-pwe3-mspw-er-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 date (May 9, 2014) is 3611 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Dutta 3 Internet-Draft M. Bocci 4 Intended status: Standards Track Alcatel-Lucent 5 Expires: November 10, 2014 L. Martini 6 Cisco Systems 7 May 9, 2014 9 Explicit Path Routing for Dynamic Multi-Segment Pseudowires 10 draft-ietf-pwe3-mspw-er-04 12 Abstract 14 Dynamic Multi-Segment Pseudowire (MS-PW) setup through an explicit 15 path may be required to provide a simple solution for 1:1 protection 16 with diverse primary and backup MS-PWs for a service, or to enable 17 controlled signaling (strict or loose) for special MS-PWs. This 18 document specifies the extensions and procedures required to enable 19 dynamic MS-PWs to be established along explicit paths. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 10, 2014. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Explicit Path in MS-PW Signaling . . . . . . . . . . . . . . 3 64 3.1. S-PE Addressing . . . . . . . . . . . . . . . . . . . . . 3 65 3.2. Explicit Route TLV (ER-TLV) . . . . . . . . . . . . . . . 3 66 3.3. Explicit Route Hop TLV (ER-Hop TLV) . . . . . . . . . . . 4 67 3.4. ER-Hop Semantics . . . . . . . . . . . . . . . . . . . . 5 68 3.4.1. ER-Hop 1: IPv4 Prefix . . . . . . . . . . . . . . . . 6 69 3.4.2. ER-Hop 2: IPv6 Prefix . . . . . . . . . . . . . . . . 6 70 3.4.3. ER-Hop 3: L2 PW Address . . . . . . . . . . . . . . . 7 71 4. Explicit Route TLV Processing . . . . . . . . . . . . . . . . 8 72 4.1. Next-Hop Selection . . . . . . . . . . . . . . . . . . . 8 73 4.2. Adding ER Hops to the Explicit Route TLV . . . . . . . . 10 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 77 8. Normative References . . . . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 Procedures for dynamically establishing multi-segment pseudowires 83 (MS-PWs), where their paths are automatically determined using a 84 dynamic routing protocol, are defined in 85 [I-D.ietf-pwe3-dynamic-ms-pw]. For 1:1 protection of MS-PWs with 86 primary and backup paths, MS-PWs SHOULD be established through a 87 diverse set of S-PEs (Switching Provider-Edge) nodes to avoid any 88 single points of failure at PW level. [I-D.ietf-pwe3-dynamic-ms-pw] 89 allows this through BGP based mechanisms. This draft proposes an 90 additional mechanism that allows the ST-PE (Source Terminating PEs) 91 to explicitly choose the path that a PW would take through the 92 intervening S-PEs. Explicit path routing of dynamic MS-PWs may also 93 be required for controlled set-up of dynamic MS-PWs and network 94 resource management. 96 2. Terminology 98 This document uses the terminology defined in 99 [I-D.ietf-pwe3-dynamic-ms-pw], [RFC4447] and [RFC5036]. 101 The following additional terminology is used: 103 Abstract Node: A group of nodes (S-PEs) representing an explicit hop 104 along the path of an MS-PW. An abstract node is identified by an 105 IPv4, IPv6 or S-PE address. 107 3. Explicit Path in MS-PW Signaling 109 This section describes the LDP (Label Distribution Protocol) 110 extensions required for signaling explicit paths in dynamic MS-PW 111 set-up messages. 113 3.1. S-PE Addressing 115 The T-PE MAY elect to select a known explicit path along a set of 116 S-PEs for a specific PW. This requires that each S-PE be uniquely 117 addressable in terms of pseudowires. For this purpose, at least one 118 AII (Attachment Individual Identifier) address of the format similar 119 to AII type 2 [RFC5003] composed of the Global ID, and Prefix part, 120 only, MUST be assigned to each S-PE. 122 If an S-PE is capable of Dynamic MS-PW signaling, but is not assigned 123 with an S-PE address, then on receiving a Dynamic MS-PW label mapping 124 message the S-PE MUST return a label release with the "Resources 125 Unavailable" ( 0x00000038)" status code. 127 3.2. Explicit Route TLV (ER-TLV) 129 The ER-TLV is an object that specifies the path to be taken by the 130 MS-PW being established. Each hop along the path is represented by 131 an abstract node, which is a group of one or more S-PEs, identified 132 by an IPv4, and IPv6 or an S-PE address. 134 The ER-TLV contains one or more Explicit Route Hop TLVs (ER-Hop TLVs) 135 defined in Section 3.3. 137 The ER-TLV format is defined as follows: 139 0 1 2 3 140 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 |U|F| Type = 0x0800 | Length | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | ER-Hop TLV 1 | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | ER-Hop TLV 2 | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 ~ ............ ~ 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | ER-Hop TLV n | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 U/F 154 These bits MUST be set to zero and the procedures of [RFC5036] 155 followed when the TLV is not known to the receiving node. 157 Type 158 A fourteen-bit field carrying the value of the ER-TLV 159 Type = 0x0800. 161 Length 162 Specifies the length of the value field in bytes. 164 ER-Hop TLVs 165 One or more ER-Hop TLVs defined in Section 3.2. 167 Explicit Route TLV 169 3.3. Explicit Route Hop TLV (ER-Hop TLV) 171 The contents of an ER-TLV are a series of variable length ER-Hop 172 TLVs. Each hop contains the identification of an "Abstract Node" 173 that represents the hop to be traversed. 175 Each ER-Hop TLV has the form: 177 0 1 2 3 178 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 |U|F| Type | Length | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 |L| Content // | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 U/F 186 These bits MUST be set to zero and the procedures of [RFC5036] 187 followed when the TLV is not known to the receiving node. 189 ER-Hop Type 191 A fourteen-bit field carrying the type of the ER-Hop contents. 192 The values are: 194 Value Type 195 ------ ------------------------ 196 0x0801 IPv4 prefix 197 0x0802 IPv6 prefix 198 0x0805 L2 PW address of PW Switching Point 200 Length 201 Specifies the length of the value field in bytes. 203 L bit 204 The L bit in the ER-Hop is a one-bit attribute. If the L bit 205 is set, then the value of the attribute is "loose." Otherwise, 206 the value of the attribute is "strict." For brevity, we say 207 that if the value of the ER-Hop attribute is loose then it is 208 a "loose ER-Hop." Otherwise, it's a "strict ER-Hop." Further, 209 we say that the abstract node of a strict or loose ER-Hop is a 210 strict or a loose node, respectively. Loose and strict nodes 211 are always interpreted relative to their prior abstract nodes. 212 The path between a strict node and its prior node MUST include 213 only network nodes from the strict node and its prior abstract 214 node. 216 The path between a loose node and its prior node MAY include 217 other network nodes, which are not part of the strict node or 218 its prior abstract node. 220 Contents 221 A variable length field containing a node or abstract node 222 which is one of the consecutive nodes that make up the 223 explicitly routed PW. 225 ER-Hop TLV 227 Details of ER Hop semantics are defined in Section 3.4. 229 3.4. ER-Hop Semantics 231 This section describes the various semantics associated with ER-HOP 232 TLV. 234 3.4.1. ER-Hop 1: IPv4 Prefix 236 The abstract node represented by this ER-Hop is the set of nodes, 237 which have an IPv4 address, which lies within this prefix. Note that 238 a prefix length of 32 indicates a single IPv4 node. 240 0 1 2 3 241 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 |U|F| Type = 0x0801 | Length = 8 | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 |L| Reserved | PreLen | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | IPv4 Address (4 bytes) | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 U/F 251 These bits MUST be set to zero and the procedures of [RFC5036] 252 followed when the TLV is not known to the receiving node. 254 Type 255 A fourteen-bit field carrying the value of the ER-Hop 1, IPv4 256 Address, Type = 0x0801 258 Length 259 Specifies the length of the value field in bytes = 8. 261 L Bit 262 Set to indicate Loose hop. 263 Cleared to indicate a strict hop. 265 Reserved 266 Zero on transmission. Ignored on receipt. 268 PreLen 269 Prefix Length 1-32 271 IP Address 272 A four-byte field indicating the IP Address. 274 ER-Hop with IPv4 Prefix 276 3.4.2. ER-Hop 2: IPv6 Prefix 278 The abstract node represented by this ER-Hop is the set of nodes, 279 which have an IPv6 address, which lies within this prefix. Note that 280 a prefix length of 128 indicates a single IPv6 node. 282 0 1 2 3 283 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 |U|F| 0x0802 | Length = 20 | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 |L| Reserved | PreLen | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | IPV6 address | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | IPV6 address (continued) | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | IPV6 address (continued) | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | IPV6 address (continued) | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 U/F 299 These bits MUST be set to zero and the procedures of [RFC5036] 300 followed when the TLV is not known to the receiving node. 302 Type 303 A fourteen-bit field carrying the value of the ER-Hop 2, IPv6 304 Address, Type = 0x0802 306 Length 307 Specifies the length of the value field in bytes = 20. 309 L Bit 310 Set to indicate Loose hop. 311 Cleared to indicate a strict hop. 313 Reserved 314 Zero on transmission. Ignored on receipt. 316 PreLen 317 Prefix Length 1-128 319 IPv6 address 320 A 128-bit unicast host addresses. 322 3.4.3. ER-Hop 3: L2 PW Address 324 The L2 PW Address follows attachment circuit addressing which is 325 derived from [RFC5003] AII type 2, as shown here: 327 0 1 2 3 328 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 |U|F| 0x0802 | Length = 18 | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 |L| Reserved | PreLen | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | AII Type=02 | Length | Global ID | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Global ID (contd.) | Prefix | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Prefix (contd.) | AC ID | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | AC ID | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 U/F 344 These bits MUST be set to zero and the procedures of [RFC5036] 345 followed when the TLV is not known to the receiving node. 347 Type 348 A fourteen-bit field carrying the value of the ER-Hop 3, L2 PW 349 Address, Type = 0x0805 351 Length 352 Specifies the length of the value field in bytes = 18. 354 L Bit 355 Set to indicate Loose hop. 356 Cleared to indicate a strict hop. 358 Reserved 359 Zero on transmission. Ignored on receipt. 361 PreLen 362 Prefix Length 1-96 364 L2 PW Address 365 An AII Address as defined in [RFC5003]. 367 4. Explicit Route TLV Processing 369 4.1. Next-Hop Selection 371 A PW Label Mapping Message containing an explicit route TLV MUST 372 specify the next hop for a given MS-PW path. Selection of this next 373 hop MAY involve a selection from a set of possible alternatives. The 374 mechanism for making a selection from this set is implementation 375 specific and is outside of the scope of this document. The mechanism 376 used to select a particular path is also outside of the scope of this 377 document, but each node MUST attempt to determine a loop-free path. 378 Note that such mechanisms MAY be overridden by local policy. 380 To determine the next hop for the MS-PW path, a node performs the 381 following steps. Note that these procedures assume that a valid S-PE 382 address has been assigned to the node, as per Section 3.1, above. 384 1. The node receiving the Label Mapping Message must evaluate the 385 first ER-Hop. If the L bit is not set in the first ER-Hop and if 386 the node is not part of the abstract node described by the first 387 ER-Hop, it has received the message in error, and MUST reply with 388 a Label Release Message with a "Bad Initial ER-Hop Error" 389 (0x04000004) status code. If the L bit is set and the local node 390 is not part of the abstract node described by the first ER-Hop, 391 the node selects a next hop that is along the path to the 392 abstract node described by the first ER-Hop. If there is no first 393 ER-Hop, the message is also in error and the node should return a 394 "Bad Explicit Routing TLV Error" (0x04000001) status code in a 395 Label Release Message sent to upstream node. 397 2. If there are no further ER-Hop TLVs following the first ER-Hop 398 TLV, this indicates the end of the explicit route. The explicit 399 route TLV MUST be removed from the Label Mapping Message. This 400 node may or may not be the end of the PW. Processing continues 401 as per Section 4.2, where a new explicit route TLV MAY be added 402 to the Label Mapping Message. 404 3. If a second ER-Hop TV does exist, and the node is also a part of 405 the abstract node described by the second ER-Hop, then the node 406 deletes the first ER-Hop and continues processing with step 2, 407 above. Note that this makes the second ER-Hop into the first ER- 408 Hop for the iteration for the next PW segment. 410 4. The node determines if it is topologically adjacent to the 411 abstract node described by the second ER-Hop. That is, it is 412 directly connected to the next node by a PW control plane 413 adjacency. If so, the node selects a particular next hop which 414 is a member of the abstract node. The node then deletes the 415 first ER-Hop and continues processing as per Section 4.2, below. 417 5. Next, the node selects a next hop within the abstract node of the 418 first ER-Hop that is along the path to the abstract node of the 419 second ER-Hop. If no such path exists then there are two cases: 421 A. If the second ER-Hop is a strict ER-Hop, then there is an 422 error and the node MUST return a Label Release Message to 423 upstream node with "Bad Strict Node Error" (0x04000002) 424 status code. 426 B. Otherwise, if the second ER-Hop is a loose ER-Hop, then the 427 node selects any next hop that is along the path to the next 428 abstract node. If no path exists within the MPLS domain, 429 then there is an error, and the node MUST return a Label 430 Release Message to upstream node with "Bad Loose Node Error" 431 (0x04000003) status code. 433 6. Finally, the node replaces the first ER-Hop with any ER-Hop that 434 denotes an abstract node containing the next hop. This is 435 necessary so that when the explicit route is received by the next 436 hop, it will be accepted. 438 7. Progress the Label Mapping Message to the next hop. 440 4.2. Adding ER Hops to the Explicit Route TLV 442 After selecting a next hop, the node may alter the explicit route in 443 the following ways. 445 If, as part of executing the algorithm in Section 4.1, the explicit 446 route TLV is removed, the node may add a new explicit route TLV. 448 Otherwise, if the node is a member of the abstract node for the first 449 ER-Hop, then a series of ER-Hops may be inserted before the First ER- 450 Hop or may replace the first ER-Hop. Each ER-Hop in this series must 451 denote an abstract node that is a subset of the current abstract 452 node. 454 Alternately, if the first ER-Hop is a loose ER-Hop, an arbitrary 455 series of ER-Hops may be inserted prior to the first ER-Hop. 457 5. IANA Considerations 459 RFC5036 [RFC5036] defines the LDP TLV name space which is maintained 460 by IANA as "LDP TLV Registry". TLV types for the Explicit Route TLV, 461 IPv4 Prefix ER-Hop TLV, and the IPv6 Prefix ER-Hop TLV are already 462 defined in the LDP TLV Registry. 464 This draft proposes one new TLV type: 466 TLV Type Suggested Value Reference 467 ------------------------------------ --------------- --------- 468 L2 PW Address of Switching Point 0x0805 Ths Document 470 6. Security Considerations 472 This document introduces no new security considerations over 473 [RFC5036], [RFC4447] and [I-D.ietf-pwe3-dynamic-ms-pw]. The security 474 considerations detailed in those documents apply to the protocol 475 extensions described in this RFC. 477 7. Acknowledgements 479 The authors gratefully acknowledge the input of Lizhong Jin. 481 8. Normative References 483 [I-D.ietf-pwe3-dynamic-ms-pw] 484 Martini, L., Bocci, M., and F. Balus, "Dynamic Placement 485 of Multi-Segment Pseudowires", draft-ietf-pwe3-dynamic-ms- 486 pw-22 (work in progress), March 2014. 488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, March 1997. 491 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 492 Heron, "Pseudowire Setup and Maintenance Using the Label 493 Distribution Protocol (LDP)", RFC 4447, April 2006. 495 [RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, 496 "Attachment Individual Identifier (AII) Types for 497 Aggregation", RFC 5003, September 2007. 499 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 500 Specification", RFC 5036, October 2007. 502 Authors' Addresses 504 Pranjal Kumar Dutta 505 Alcatel-Lucent 506 701 E Middlefield Road 507 Mountain View, California 94043 508 USA 510 Email: pranjal.dutta@alcatel-lucent.com 511 Matthew Bocci 512 Alcatel-Lucent 513 Voyager Place, Shoppenhangers Road 514 Maidenhead, Berks SL6 2PJ 515 UK 517 Email: matthew.bocci@alcatel-lucent.com 519 Luca Martini 520 Cisco Systems 521 9155 East Nichols Avenue, Suite 400 522 Englewood, Colorado 80112 523 USA 525 Email: lmartini@cisco.com