idnits 2.17.1 draft-ietf-pwe3-packet-pw-00.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 (January 11, 2011) is 4846 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (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) == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-fat-pw-05 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bryant, Ed. 3 Internet-Draft L. Martini 4 Intended status: BCP G. Swallow 5 Expires: July 15, 2011 Cisco Systems 6 A. Malis 7 Verizon Communications 8 January 11, 2011 10 Packet Pseudowire Encapsulation over an MPLS PSN 11 draft-ietf-pwe3-packet-pw-00.txt 13 Abstract 15 This document describes a pseudowire mechanism that is used to 16 transport a packet service over an MPLS PSN is the case where the 17 client LSR and the server PE are co-resident in the same equipment. 18 This pseudowire mechanism may be used to carry all of the required 19 layer 2 and layer 3 protocols between the pair of client LSRs. 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 [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 July 15, 2011. 44 Copyright Notice 46 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Network Reference Model . . . . . . . . . . . . . . . . . . . 3 63 3. Client Network Layer Model . . . . . . . . . . . . . . . . . . 4 64 4. Forwarding Model . . . . . . . . . . . . . . . . . . . . . . . 5 65 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 6 66 6. Encapsulation Approaches Considered . . . . . . . . . . . . . 7 67 6.1. A Protocol Identifier in the Control Word . . . . . . . . 7 68 6.2. PID Label . . . . . . . . . . . . . . . . . . . . . . . . 7 69 6.3. Parallel PWs . . . . . . . . . . . . . . . . . . . . . . . 8 70 6.4. Virtual Ethernet . . . . . . . . . . . . . . . . . . . . . 9 71 6.5. Recommended Encapsulation . . . . . . . . . . . . . . . . 10 72 7. Packet PW Encapsulation . . . . . . . . . . . . . . . . . . . 10 73 8. Ethernet Functional Restrictions . . . . . . . . . . . . . . . 11 74 9. Congestion Considerations . . . . . . . . . . . . . . . . . . 12 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 78 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 13.1. Normative References . . . . . . . . . . . . . . . . . . . 12 80 13.2. Informative References . . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 There is a need to provide a method of carrying a packet service over 86 an MPLS PSN in a way that provides isolation between the two 87 networks. The server MPLS network may be an MPLS network or a 88 network conforming to the MPLS-TP [RFC5317]. The client may also be 89 either a MPLS network of a network conforming to the MPLS-TP. 90 Considerations regarding the use of an MPLS network as a server for 91 an MPLS-TP network are outside the scope of this document. 93 Where the client equipment is connected to the server equipment via 94 physical interface, the same data-link type MUST be used to attach 95 the clients to the Provider Edge equipments (PE)s, and a pseudowire 96 (PW) of the same type as the data-link MUST be used [RFC3985]. The 97 reason that inter-working between different physical and data-link 98 attachment types is specifically disallowed in the pseudowire 99 architecture is because this is a complex task and not a simple bit- 100 mapping exercise. The inter-working is not limited to the physical 101 and data-link interfaces and the state-machines. It also requires a 102 compatible approach to the formation of the adjacencies between 103 attached client network equipment. As an example the reader should 104 consider the differences between router adjacency formation on a 105 point to point link compared to a multi-point to multi-point 106 interface (e.g. Ethernet). 108 A further consideration is that two adjacent MPLS LSRs do not simply 109 exchange MPLS packets. They exchange IP packets for adjacency 110 formation, control, routing, label exchange, management and 111 monitoring purposes. In addition they may exchange data-link packets 112 as part of routing (e.g. IS-IS hellos and IS-IS LSPs) and for OAM 113 purposes such as Link Layer Discovery protocol [IEEE standard 114 802.1AB-2009]. Thus the two clients require an attachment mechanism 115 that can be used to multiplex a number of protocols. In addition it 116 is essential to the correct operation of the network layer that all 117 of these protocols fate share. 119 Where the client LSR and server PE is co-located in the same 120 equipment, the data-link layer can be simplified to a simple protocol 121 identifier (PID) that is used to multiplex the various data-link 122 types onto a pseudowire. This is the method that described in this 123 document. 125 2. Network Reference Model 127 The network reference model for the packet pseudowire operating in an 128 MPLS network is shown in Figure 1. This is an extension of Figure 3 129 "Pre-processing within the PWE3 Network Reference Model" from 131 [RFC3985]. 133 PW PW 134 End Service End Service 135 | | 136 |<------- Pseudowire ------->| 137 | | 138 | Server | 139 | |<- PSN Tunnel ->| | 140 | V V | 141 ------- +-----+-----+ +-----+-----+ ------- 142 ) | | |================| | | ( 143 client ) | MPLS| PE1 | PW1 | PE2 | MPLS| ( Client 144 MPLS PSN )+ LSR1+............................+ LSR2+( MPLS PSN 145 ) | | | | | | ( 146 ) | | |================| | | ( 147 ------- +-----+-----+ +-----+-----+ -------- 148 ^ ^ 149 | | 150 | | 151 |<---- Emulated Service----->| 152 | | 153 Virtual physical Virtual physical 154 termination termination 156 Figure 1 158 In this model LSRs, LSR1 and LSR2, are part of the client MPLS packet 159 switched network (PSN). The PEs, PE1 and PE2 are part of the server 160 PSN, that is to be used to provide connectivity between the client 161 LSRs. The attachment circuit that is used to connect the MPLS LSRs 162 to the PEs is a virtual interface within the equipment. A packet 163 pseudowire is used to provide connectivity between these virtual 164 interfaces. This packet pseudowire is used to transport all of the 165 required layer 2 and layer 3 between protocols between LSR1 and LSR2. 167 3. Client Network Layer Model 169 The packet PW appears as a single point to point link to the client 170 layer. Network Layer adjacency formation and maintenance between the 171 client equipments will the follow normal practice needed to support 172 the required relationship in the client layer. The assignment of 173 metrics for this point to point link is a matter for the client 174 layer. In a hop by hop routing network the metrics would normally be 175 assigned by appropriate configuration of the embedded client network 176 layer equipment (e.g. the embedded client LSR). Where the client was 177 using the packet PW as part of a traffic engineered path, it is up to 178 the operator of the client network to ensure that the server layer 179 operator provides the necessary service level agreement. 181 4. Forwarding Model 183 The packet PW forwarding model is illustrated in Figure 2. The 184 forwarding operation can be likened to a virtual private network 185 (VPN), in which a forwarding decision is first taken at the client 186 layer, an encapsulation is applied and then a second forwarding 187 decision is taken at the server layer. 189 +------------------------------------------------+ 190 | | 191 | +--------+ +--------+ | 192 | | | Pkt +-----+ | | | 193 ------+ +---------+ PW1 +--------+ +------ 194 | | Client | AC +-----+ | Server | | 195 Client | | LSR | | LSR | | Server 196 Network | | | Pkt +-----+ | | | Network 197 ------+ +---------+ PW2 +--------+ +------ 198 | | | AC +-----+ | | | 199 | +--------+ +--------+ | 200 | | 201 +------------------------------------------------+ 203 Figure 2: Packet PW Forwarding Model 205 A packet PW PE comprises three components, the client LSR, PW 206 processor and a server LSR. Note that [RFC3985] does not formally 207 indicate the presence of the server LSR because it does not concern 208 itself with the server layer. However it is useful in this document 209 to recognise that the server LSR exists. 211 It may be useful to first recall the operation of a layer two PW such 212 as an Ethernet PW [RFC4448] within this model. The client LSR is not 213 present and packets arrive directly on the attachment circuit (AC) 214 which is part of the client network. The PW undertakes any header 215 processing, if configured to do so, it then pushes the PW control 216 word (CW), and finally pushes the PW label. The PW function then 217 passes the packet to the LSR function which pushes the label needed 218 to reach the egress PE and forwards the packet to the next hop in the 219 server network. At the egress PE, the packet typically arrives with 220 the PW label at top of stack, the packet is thus directed to the 221 correct PW instance. The PW instance performs any required 222 reconstruction using, if necessary, the CW and the packet is sent 223 directly to the attachment circuit. 225 Now let us consider the case client layer MPLS traffic being carried 226 over a packet PW. An LSR belonging to the client layer is embedded 227 within the PE equipment. This is a type of native service processing 228 element [RFC3985]. This LSR determines the next hop in the client 229 layer, and pushes the label needed by the next hop in the client 230 layer. It then passes the packet to the correct PW instance 231 indicating the packet protocol type. If the PW is configured to 232 require a CW this is pushed. The PW instance then examines the 233 protocol type and pushes a label that identifies the protocol type to 234 the egress PE. The PW instance then proceeds as it would for a layer 235 two PW, by pushing the PW label and then handing the packet to the 236 server layer LSR for delivery. At egress, the packet again arrives 237 with the PW label at the top of stack which causes the packet to be 238 passed to the correct PW instance. This PW instance knows that the 239 PW type is a packet PW, and hence that it needs to interpret the next 240 label as a protocol type identifier. If necessary the CW is then 241 popped and processed. The packet is then passed to the egress client 242 LSR together with information that identifies the packet protocol 243 type. The egress client LSR then forwards the packet in the normal 244 manner for a protocol of that type. 246 Note that although the description above is written in terms of the 247 behaviour of an MPLS LSR, the processing model would be similar for 248 an IP packet, or indeed any other protocol type. 250 Note that the semantics of the PW between the client LSRs is a point 251 to point link. 253 5. Design Considerations 255 A number of approaches to the design of a packet pseudowire (PW) have 256 been investigated and have been described at the IETF. This section 257 discusses the approaches that were analysed and the technical issues 258 that the authors took into consideration in arriving at the proposed 259 approach. 261 In a typical network there are usually no more that four network 262 layer protocols that need to be supported: IPv4, IPv6, MPLS and CLNS 263 although any solution needs to be scalable to a larger number of 264 protocols. The approaches considered in this document all satisfy 265 this minimum requirement, but vary in their ability to support larger 266 numbers of network layer protocols. 268 Additionally it is beneficial if the complete set of protocols 269 carried over the network between in support of a set of CE peers fate 270 share. It is additionally beneficial if a single OAM session can be 271 used to monitor the behaviour of this complete set. During the 272 investigation various views were expressed as to where on the scale 273 from absolutely required to "nice to have" these benefits lay, but in 274 the end they were not a factor in reaching our conclusion. 276 6. Encapsulation Approaches Considered 278 There are four candidate approaches that have been analysed: 280 1. A protocol identifier (PID) in the PW Control Word (CW) 282 2. A PID label 284 3. Parallel PWs - one per protocol. 286 4. Virtual Ethernet 288 6.1. A Protocol Identifier in the Control Word 290 This is the approach that we proposed in draft 0 of this document . 291 The proposal was that a Protocol Identifier (PID) would included in 292 the PW control word (CW), by appending it to the generic control word 293 [RFC5385] to make a 6 byte CW (the version 0 draft actually included 294 two reserved bytes to provide 32bit alignment, but let us assume that 295 was optimized out). A variant of this is just to use a 2 byte PID 296 without a control word. 298 This is a simple approach, and is basically a virtual PPP interface 299 without the PPP control protocol. This has a smaller MTU than for 300 example a virtual Ethernet would need, however in forwarding terms it 301 is not as simple as the PID label or multiple PW approaches described 302 next, and may not be deployable on a number of existing hardware 303 platforms. 305 6.2. PID Label 307 This is the approach that we described in Version 2 of this document. 308 The in this mechanism the PID is indicated by including a label after 309 the PW label that indicates the protocol type as shown in Figure 3. 311 +-------------------------------+ 312 | Client | 313 | Network Layer | 314 | packet | n octets 315 | | 316 +-------------------------------+ 317 | Optional Control Word | 4 octets 318 +-------------------------------+ 319 | PID Label (S=1) | 4 Octets 320 +-------------------------------+ 321 | PW label | 4 octets 322 +-------------------------------+ 323 | Server MPLS Tunnel Label(s) | n*4 octets (four octets per label) 324 +-------------------------------+ 326 Figure 3: Encapsulation of a pseudowire with a pseudowire load 327 balancing label 329 In the PID Label approach a new Label Distribution protocol (LDP) 330 Forwarding Equivalence Class (FEC) element is used to signal the 331 mapping between protocol type and the PID label. This approach 332 complies with RFC3031. 334 A similar approach to PID label is described in Section 3.4.5 of 335 [RFC5921]. In this case when the client is a network layer packet 336 service such as IP or MPLS, a service label and demultiplexer label 337 (which may be combined) is used to provide the necessary 338 identifications needed to carry this traffic over an LSP. 340 The authors surveyed the hardware designs produced by a number of 341 companies across the industry and concluded that whilst the approach 342 complies with the MPLS architecture, it may conflict with a number of 343 designer's interpretation of the existing MPLS architecture. This 344 led to concerns that the approach may result in unexpected 345 difficulties in the future. Specifically there is an assumption in 346 many designs that a forwarding decision should be made on the basis 347 of a single label. Whilst the approach is attractive, it cannot be 348 supported by many commodity chip sets and this would require new 349 hardware which would increase the cost of deployment and delay the 350 introduction of a packet PW service. 352 6.3. Parallel PWs 354 In this approach one PW is constructed for each protocol type that 355 must be carried between the PEs. Thus a complete packet PW would 356 therefore consist of a bundle of PWs . This model would be very 357 simple and efficient from a forwarding point of view. The number of 358 parallel PWs required would normally be relatively small. In a 359 typical network there are usually no more that four network layer 360 protocols that need to be supported: IPv4, IPv6, MPLS and CLNS 361 although any solution needs to be scalable to a larger number of 362 protocols. 364 The are a number of serious downsides with this approach: 366 1. From an operational point of view the lack of fate sharing 367 between the protocol types can lead to complex faults which are 368 difficult to diagnose. 370 2. There is an undesirable trade off in the OAM related to the first 371 point. Either we would have to run an OAM on each PW and bind 372 them together which lead to significant protocol and software 373 complexity and does not scale well. Alternatively we would need 374 to run a single OAM session on one of the PWs as a proxy for the 375 others and the diagnose any more complex failure on a case by 376 case basis. To some extent the issue of fate sharing between 377 protocol in the bundle (for example the assumed fate sharing 378 between CLNS and IP in IS-IS) can be mitigated through the use of 379 BFD. 381 3. The need to configure manage and synchronize the behaviour of a 382 group of PWs as if they were a single PW leads to an increase in 383 control plane complexity. 385 The Parallel PW mechanism is therefore an approach which simplifies 386 the forwarding plane, but only at a cost of a considerable increase 387 in other aspects of the design and in particular operation of the PW. 389 6.4. Virtual Ethernet 391 Using a virtual Ethernet to provide a packet PW would require PEs to 392 include a virtual (internal) Ethernet interface and then to use an 393 Ethernet PW [RFC4448] to carry the user traffic. This is 394 conceptually simple and can be implemented today without any further 395 standards action, although there are a number of applicability 396 considerations that it is useful to draw to the attention of the 397 community. 399 Conceptually this is a simple approach and some deployed equipments 400 can already do this. However the requirement to run a complete 401 Ethernet adjacency lead us to conclude that there was a need to 402 identify a simpler approach. The packets encapsulated in an Ethernet 403 header have a larger MTU than the other approaches, although this is 404 not considered to be an issue on the networks needing to carry packet 405 PWs. 407 The virtual Ethernet mechanism was the first approach that the 408 authors considered, before the merits of the other approaches 409 appeared to make them more attractive. As we shall see below 410 however, the other approaches were not without issues and it appears 411 that the virtual Ethernet is preferred approach to providing a packet 412 PW. 414 6.5. Recommended Encapsulation 416 The operational complexity and the breaking of fate sharing 417 assumptions associated with the parallel PW approach would suggest 418 that this is not an approach that should be further pursued. 420 The PID Label approach gives rise to the concerns that it will break 421 implicit behavioural and label stack size assumptions in many 422 implementations. Whilst those assumptions may be addressed with new 423 hardware this would delay the introduction of the technology to the 424 point where it was unlikely to gain acceptance in competition with an 425 approach that needed no new protocol design and is already 426 supportable on many existing hardware platforms. 428 The PID in the CW leads to the most compact protocol stack, is simple 429 and requires minimal protocol work. However it is a new forwarding 430 design, and apart from the issue of the larger packet header and the 431 simpler adjacency formation offers no advantage over the virtual 432 Ethernet. 434 The above considerations bring us back to the virtual Ethernet, which 435 is a well known protocol stack, with a well known (internal) client 436 interface. It is already implemented in many hardware platforms and 437 is therefore readily deployable. The authors conclude that having 438 considered a number of initially promising alternatives, the 439 simplicity and existing hardware make the virtual Ethernet approach 440 to the packet PW the most attractive solution. 442 7. Packet PW Encapsulation 444 The client network work layer packet encapsulation into a packet PW 445 is shown in Figure 4. 447 +-------------------------------+ 448 | Client | 449 | Network Layer | 450 | packet | n octets 451 | | 452 +-------------------------------+ 453 | | 454 | Ethernet | 14 octets 455 | Header | 456 | +---------------+ 457 | | 458 +---------------+---------------+ 459 | Optional Control Word | 4 octets 460 +-------------------------------+ 461 | Optional FAT Label (S=1) | 4 octets 462 +-------------------------------+ 463 | PW label | 4 octets 464 +-------------------------------+ 465 | Server MPLS Tunnel Label(s) | n*4 octets (four octets per label) 466 +-------------------------------+ 468 Figure 4 470 This conforms to the PW protocols stack as defined in [RFC4448] and 472 [I-D.ietf-pwe3-fat-pw]. 474 This is unremarkable except to note that the stack does not retain 32 475 bit alignment between the virtual Ethernet header and the PW optional 476 control word (or the PW label when the optional components are not 477 present in the PW header). This loss of 32 bit of alignment is 478 necessary to preserve backwards compatibility with the Ethernet PW 479 design [RFC4448] 481 Considerations concerning the allocation of a suitable Ethernet 482 address the virtual Ethernet will be discussed in a future version of 483 this document. 485 8. Ethernet Functional Restrictions 487 The use of Ethernet as the encapsulation mechanism for traffic 488 between the server LSRs is a convenience based on the widespread 489 availability of existing hardware. In this application there is no 490 requirement for any Ethernet feature other than its protocol 491 multiplexing capability. Thus, for example, the Ethernet OAM is NOT 492 REQUIRED. 494 The use and applicability of Ethernet VLANs, 802.1p, and 802.1Q 495 between PEs will be discussed in a future revision. 497 Point to multipoint and multipoint to multipoint operation of the 498 virtual Ethernet is not supported. 500 9. Congestion Considerations 502 A packet pseudowire is normally used to carry IP, MPLS and their 503 associated support protocols over an MPLS network. There are no 504 congestion considerations beyond those that ordinarily apply to an IP 505 or MPLS network. Where the packet protocol being carried is not IP 506 or MPLS and the traffic volumes are greater than that ordinarily 507 associated with the support protocols in an IP or MPLS network, the 508 congestion considerations being developed for PWs apply [RFC3985], 509 [RFC5659]. 511 10. Security Considerations 513 The virtual Ethernet approach to packet PW introduces no new security 514 risks. A more detailed discussion of pseudowire security is given in 515 [RFC3985], [RFC4447] and [RFC3916]. 517 11. IANA Considerations 519 This section may be removed on publication. 521 There are no IANA action required by the publication of this 522 document. 524 12. Acknowledgements 526 The authors acknowledge the contribution make by Sami Boutros, Giles 527 Herron, Siva Sivabalan and David Ward to this document. 529 13. References 531 13.1. Normative References 533 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 534 Requirement Levels", BCP 14, RFC 2119, March 1997. 536 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 538 Heron, "Pseudowire Setup and Maintenance Using the Label 539 Distribution Protocol (LDP)", RFC 4447, April 2006. 541 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, 542 "Encapsulation Methods for Transport of Ethernet over MPLS 543 Networks", RFC 4448, April 2006. 545 13.2. Informative References 547 [I-D.ietf-pwe3-fat-pw] 548 Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 549 J., and S. Amante, "Flow Aware Transport of Pseudowires 550 over an MPLS PSN", draft-ietf-pwe3-fat-pw-05 (work in 551 progress), October 2010. 553 [RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for 554 Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, 555 September 2004. 557 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 558 Edge (PWE3) Architecture", RFC 3985, March 2005. 560 [RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) 561 Report on MPLS Architectural Considerations for a 562 Transport Profile", RFC 5317, February 2009. 564 [RFC5385] Touch, J., "Version 2.0 Microsoft Word Template for 565 Creating Internet Drafts and RFCs", RFC 5385, 566 February 2010. 568 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 569 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 570 October 2009. 572 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 573 Berger, "A Framework for MPLS in Transport Networks", 574 RFC 5921, July 2010. 576 Authors' Addresses 578 Stewart Bryant (editor) 579 Cisco Systems 580 250, Longwater, Green Park, 581 Reading, Berks RG2 6GB 582 UK 584 Email: stbryant@cisco.com 586 Luca Martini 587 Cisco Systems 588 9155 East Nichols Avenue, Suite 400 589 Englewood, CO 80112 590 USA 592 Email: lmartini@cisco.com 594 George Swallow 595 Cisco Systems 596 1414 Massachusetts Ave 597 Boxborough, MA 01719 598 USA 600 Email: swallow@cisco.com 601 URI: 603 Andy Malis 604 Verizon Communications 605 117 West St. 606 Waltham, MA 02451 607 USA 609 Email: andrew.g.malis@verizon.com