Network Working Group Luca Martini (Editor) Internet Draft Cisco Systems Inc. Expiration Date: June 2005 Matthew Bocci (Editor) Nabil Bitar (Editor) Alcatel Verizon December 2004 Requirements for inter domain Pseudo-Wires draft-martini-pwe3-MH-PW-requirements-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes the necessary requirements to allow a service provider to extend the reach of pseudo-wires across multiple domains. These domains can be autonomous systems under one provider administrative control, IGP areas in one autonomous system, different autonomous systems under the administrative control of two or more Martini, et al. [Page 1] Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004 service providers, or administratively established pseudowire domains. Table of Contents 1 Specification of Requirements .......................... 2 2 Acknowledgements ....................................... 3 3 Introduction ........................................... 3 3.1 Scope .................................................. 3 3.2 Architecture ........................................... 3 4 Terminology ............................................ 6 5 Use Cases .............................................. 6 6 Multi-Hop Pseudo Wire Requirements ..................... 9 6.1 Architecture ........................................... 9 6.2 Traffic Engineering .................................... 10 6.3 Quality of Service ..................................... 10 6.4 Routing ................................................ 12 6.5 Signalling ............................................. 12 6.6 Operations and Maintenance (OAM) ....................... 12 7 Security Considerations ................................ 14 8 Full Copyright Statement ............................... 14 9 Intellectual Property Statement ........................ 14 10 Normative References ................................... 15 11 Informative References ................................. 15 12 Informative References ................................. 15 13 Author Information ..................................... 15 1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 Martini, et al. [Page 2] Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004 2. Acknowledgements The editors gratefully acknowledge the following contributors: Dimitri Papadimitriou (Alcatel), Peter Busschbach (Lucent), Sasha Vainshtein (Axerra), Richard Spencer (British Telecom), Simon Delorde (France Telecom), Deborah Brungard (AT&T), Rahul Aggawal (Juniper), Du Ke (ZTE), Cagatay Buyukkoc (ZTE). 3. Introduction 3.1. Scope This document specifies requirements for extending pseudo-wires across more than one packet switched network (PSN) domain. These pseudo-wires are called multi-hop pseudo-wires (MH-PW). Requirements for single-hop pseudo-wires (SH-PW) that extend edge to edge across only one PSN domain are specified in [PWE3-REQ]. This document specifies additional requirements that apply to MH-PWs. These requirements do not apply to PSNs that only support SH-PWs. 3.2. Architecture The following two figures describe the reference models which are derived from [PWE3-ARCH] to support PW emulated services. Martini, et al. [Page 3] Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004 |<-------------- Emulated Service ---------------->| | | | |<------- Pseudo Wire ------>| | | | | | | | |<-- PSN Tunnel -->| | | | PW End V V V V PW End | V Service +----+ +----+ Service V +-----+ | | PE1|==================| PE2| | +-----+ | |----------|............PW1.............|----------| | | CE1 | | | | | | | | CE2 | | |----------|............PW2.............|----------| | +-----+ ^ | | |==================| | | ^ +-----+ ^ | +----+ +----+ | | ^ | | Provider Edge 1 Provider Edge 2 | | | | | | Customer | | Customer Edge 1 | | Edge 2 | | | | Attachment Circuit (AC) Attachment Circuit (AC) native ethernet service native ethernet service Figure 1: PWE3 Reference Configuration Figure 1 shows the PWE3 reference architecture [PWE3-ARCH]. This architecture applies to the case where a PSN tunnel extends between two edges of a single PSN domain to transport a PW with endpoints at these edges. Martini, et al. [Page 4] Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004 Native |<-----------Pseudo Wire----------->| Native Layer2 | | Layer2 Service | |<-PSN1-->| |<--PSN2->| | Service (AC) V V V V V V (AC) | +----+ +-----+ +----+ | +----+ | | PE1|=========| PE2 |=========| PE3| | +----+ | |----------|........PW1.........|...PW3........|----------| | | CE1| | | | | | | | | |CE2 | | |----------|........PW2.........|...PW4........|----------| | +----+ | | |=========| |=========| | | +----+ ^ +----+ +-----+ +----+ | ^ | Provider Edge 1 ^ Provider Edge 3 | | | | | | | | PW switching point | | (Optional PW adaptation function) | | | |<------------------- Emulated Service ------------------>| Figure 2: PW switching Reference Model Figure 2 extends this architecture to show a multihop case. PE1 and PE3 provide PWE3 to CE1 and CE2. These PEs reside in different PSNs. A PSN tunnel extends from PE1 to PE2 across PSN1, and a second PSN tunnel extends from PE2 to PE3 across PSN2. PWs are used to connect the Attachment circuits (ACs) attached to PE1 to the corresponding ACs attached to PE3. Each PW on the tunnel across PSN1 is stitched to a PW in the tunnel across PSN2 at PE2 to complete the multi-hop PW (MH-PW) between PE1 and PE3. PE2 is therefore the PW switching point and will be referred to as the PW switching provider edge (S-PE). PW1 and PW3 are segments of the same MH-PW while PW2 and PW4 are segments of another pseudowire. PW segments of the same MH-PW (e.g., PW1 and PW3) MUST be of the same PW type, but PSN tunnels (e.g., PSN1 and PSN2) can be the same or different technology. Note that although Figure 2 only shows a single S-PE, a PW may transit more than one S-PE along its path. Martini, et al. [Page 5] Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004 4. Terminology [PWE3-REQ] provides terminology for PWE3. This document defines the following additional terms: - Ultimate PE (U-PE). A PE where the customer-facing ACs (attachment circuits) are bound to a PW forwarder. An ultimate PE is present in the first and last segments of a MH-PW. - Single-Hop PW (SH-PW). A PW setup directly between two U-PE devices. - Multi-hop PW (MH-PW). A static or dynamically configured set of two or more contiguous PW segments (SH-PW) that behave and function as a single point-to-point PW. Each end of a MH-PW by definition MUST terminate on a U-PE. - PW Switching Point (S-PE). A PE capable of switching the control and data planes of the preceding and succeeding PW segments (SH- PW) in a MH-PW. A PW Switching Point is never the S-PE and the U-PE for a MH-PW. A PW switching point runs necessary protocols to setup and manage PW segments with other PW switching points and ultimate PEs. - PW Segment. A part of Multi-hop PW, which is set up between two PE devices, U-PEs and/or S-PEs. - PW access point address. A PWE3 payload (special service) is a client, while the PSN is a server layer in the client/server model as specified in [ITU] ITU G.805 & G.809. The Client layer service access the server layer at the access point address. 5. Use Cases PWE3 defines the signaling and encapsulation techniques for establishing SH-PWs between a pair of ultimate PEs and in the vast majority of cases this will be sufficient. MH-PWs are a solution to the following limitations of SH-PWs: -i. Inter-Provider PWs: An Inter-Provider PW is a PW that extends from a U-PE in one provider domain to a U-PE in another provider domain. The need for interprovider PWs arises from the desire to use a common or converged packet interface (e.g., MPLS) between two provider domains to carry multiple services (i.e., IP, ATM over MPLS, etc.). It may not be possible, desirable or feasible to establish a Martini, et al. [Page 6] Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004 PW control channel between the ultimate source and destination PEs to establish an an interprovider PW, as required for SH-PW. At a minimum PW control channel establishment requires knowledge of and reachability to the remote (ultimate) PE IP address. The local (ultimate) PE may not have access to this information due to operational or security constraints. Moreover, a SH-PW would require the existing of a PSN tunnel between the local U-PE and the remote U-PE. It may not be feasible or desirable to extend contiguous PSN tunnels between U-PEs in one domain and U-PEs in another domain for security and/or scalability reasons or for the fact that the two domains may be using different PSN technologies. SH-PW setup, maintainance and forwarding procedures do not address the various constraints encountered in a multi- provider environment. MH-PW setup and maintainance procedures must be designed to satisfy requirements placed by these constraints. An example is the inter-AS L2VPN scenario where the ultimate PEs reside in different provider networks (ASs) and it is the practice to MD5-key all control traffic exchanged between two networks. Technically a SH-PW could be used but this would require MD5-keying on ALL ultimate source and destination PE nodes. An MH-PW allows the providers to confine MD5 key administration to just the PW switching points connecting the two domains. -ii. PW Scaling Issues: There is a requirement to deploy PWs edge to edge in large service provider networks. Such networks typically encompass 100's or thousands of aggregation devices at the edge, each of which would be a PE. A single hop pseudo-wire architecture would require that a full mesh of PSN tunnels be provisioned to allow PWs to be established between all PEs. This is not a scalable solution. In a network of N PEs, the SH-PW solution requires at least N2 unidirectional PSN tunnels to be established and managed in the newtork, and at least (2*N-2) unidirectional PSN tunnels to be terminated on each PE. It also requires each PE to maintain (N-1) PW signaling adjacencies, one to every other PE in the network. Thus, in a single provider network of 1000 PEs, the SH-PW solution would require a minimum of one million unidirectional PSN tunnels in the network, a minimum of 1998 unidirectional PSN tunnels per PE, and a total of 999 PW signaling adjacencies per PE. Interprovider PWs further aggravate this scalability problem. Martini, et al. [Page 7] Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004 If PWs are to be setup between PEs of two provider networks with 1000 PEs each, the SH-PW solution would require a total of 4 million unidirectional PSN tunnels in the combined network, 3998 unidirectional PSN tunnels per PE and a total of 1999 PW signaling adjacencies per PE. In order to reduce the scaling problem, there is therefore a requirement either to support a sparse mesh of PSN tunnels and PW signaling adjacencies, or to partition the network into a number of smaller PWE3 domains. In either case, a PW would have to pass through more than one PSN tunnel hops along its path. -iii. PSN Internetworking PWE3 signaling protocols and PSN types may differ in different provider networks. The ultimate PEs may be connected to networks employing different PW signaling and /or PSN protocols. In this case it is not possible to use a SH-PW. A MH-PW with the appropriate interworking performed at the PW switching points can enable PW connectivity between the ultimate PEs in this scenario. -iv. Pseudo-Wires in Access and Metro Networks Service providers are looking to extend PWs to access and metro networks. The prime motive is cost reduction in capital and operation expenses. For instance, in metro networks, providers are looking into extending PWs to next generation SONET ADMs using MPLS mechanisms. The objective is to increase the gain OBfrom packet statistical multiplexing at an earlier point in the network, reducing the recurring costs of SONET circuits or maximizing the utilization of existing SONET infrastructure. In access and metro Ethernet networks, providers are looking to gain advantage of MPLS mechanisms to setup point to point Ethernet virtual circuits with endpoints in the same or different access/metro networks. If the SH-PW solution is to be used in these cases, every edge access or edge metro device with PW endpoints needs to beome a PE from the PWE3 architecture viewpoint. This results in increaing the number of PEs in a single provider network from 100s and 1000s to 10s of thousands, further aggrvating the scalability problem discussed in the previous section. In addition, if these PEs are to become part of the same IGP domain as the rest of the provider MPLS network, a routing scalability problem will arise. Using the MH-PW solution, access and metro network elements need only maintain PW signaling adjacencies with the PEs to which they connect. They do not need PW signaling Martini, et al. [Page 8] Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004 adjacencies with every other access and metro network device. PEs in the PSN backbone in turn maintain PW signaling adjacencies among each other. In addition, a PSN tunnel is setup between an access element and the PE to which it connects. Another PSN tunnel needs to be established between every PE pair in the PSN backbone. A MH-PW may be setup from one access network element to another another access element with three segments: (1) access-element - PSN PE, (2) PSN-PE to PSN-PE, and (3) PSN- PE to access element. In this MH-PW setup, access elements are U-PEs while PSN-PEs are S-PEs. It should be noted that the PSN backbone can be also segmented into PWE3 domains with more segments per PW. 6. Multi-Hop Pseudo Wire Requirements 6.1. Architecture The following requirements apply to the architecture for MH-PWs: -i. Client-server transparency MUST be maintained at each layer. That is, the PW type (i.e. ATM, Ethernet, etc) MUST be transparent to the S-PEs in the forwarding plane, except for the functions needed for interworking PW transport over different PSN types. (N.B: I added the last two sentences, but I still do not like the wording here suggest the following:) S-PEs MAY only support switching PWs of the same type. In this case, the PW type is transparent to the S-PE in the forwarding plane, except for functions needed to provide for interworking between different PSN technologies. -ii. If MH-PWs are tunneled, using a PSN tunnel overlay, across a SH-PW PSN, then only the requirements of [PWE3-REQ] apply to the SH-PW PSN. The fact that the overlay is carrying MH-PWs MUST be transparent to the routers in the SH-PW PSN. -iii. The PWs MUST be transparent to the P-routers. A P-router is not an S-PE or an U-PE from the MH-PW architecture viewpoint. P-routers provide transparaent PSN transport for PWs. -iv. The MH-PWs MUST use the same encapsulation modes specified for SH-PWs. Martini, et al. [Page 9] Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004 -v. S-PEs MAY change the type or encapsulation mode of a PW. This enables the establishment of a MH-PW between two PEs with different encapsulation capability. -vi. A MH-PW SHOULD be able to pass across PSNs of all technologies specified by PWE3 for SH-PWs. When crossing from one PSN technology to another, an S-PE must provide the necessary interowrking functions. 6.2. Traffic Engineering The following requirements apply to the traffic engineering of MH- PWs: -i. Upon setting us a pseudowire, S-PEs and U-PEs MUST be able to perform admission control for the PW over the PSN to ensure that PW bandwidth and QoS requirements can be satisfied. Since the PW is tunneled in a PSN tunnel, the PW must be admitted at tunnel ingress in the direction of traffic. Restrictions may apply depending on the PSN tunnel types. -ii. When seitting up a MH-PW, S-PEs and U-PEs MUST be able to select a path across the PSN that satisfies the MH-PW QoS and bandwidth requirements. Restrictions may apply depending on the method used for setting up a PW segment and on PSN tunnel types. -iii. Bandwidth SHOULD be reserved in the PSN during the PW routing phase to support the bandwidth requirements of the MH-PW and keep to track of available resources. -iv. Mechanisms to protect a MH-PW when an S-PE fails MUST be provided. 6.3. Quality of Service Pseudo wires are intended to support services (e.g., TDM and ATM) which may have strict per-connection Quality of Service requirements. This may include either absolute or relative guarantees on packet loss, delay, and jitter. These guarantees are in part delivered by reserving sufficient network resources (e.g. BW), and by providing appropriate per-packet treatment (e.g. scheduling priority and drop precedence) at queueing points. In SH-PWs, a traffic engineered PSN tunnel (i.e., MPLS-TE) may be Martini, et al. [Page 10] Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004 used to ensure that sufficient resources are reserved in the P- routers to provide QoS to PWs on the tunnel. In this case, resource management (e.g. admission control of PWs onto the PSN tunnel) MUST occur at the ingress PE. The per-packet treatment for PWs on the P- routers and core facring interfaces on the U-PEs will be based on the exp bits in the MPLS tunnel header. For MH-PWs, each S-PE maps a PW to a PSN tunnel. That is, an S-PE decides what PW to bind to which PSN tunnel. Control over binding a PW to a PSN tunnel must be provided. Ideally, the PSN tunnel SHOULD have better QoS or same QoS characteristics as the carried PW. However, in certain cases, an operator may need to bind a PW to a PSN tunnel with nominally lower QoS characteristics. For MH-PWs, each S-PE may represent a point of contention for resources of the PSN tunnels. Therefore, during contention for network resources, S-PEs should enable the appropriate QoS treatment for packets on different PWs that are multiplexed into the same PSN tunnel. Such treatment may be indicated, by the EXP bit values of the packet in the tunnel header. It must also be possible to reserve sufficient resources at each S-PE for the PWs, and to reject attempts to establish PWs on tunnels that do not have sufficient available resources to satisfy the QoS requirements of existing PWs, the new PW, and other services on those tunnels. Such a PW admission control function may reside on the S-PE, but it may also reside outside of the S-PE. If it resides on the S- PE, then the PW signalling protocol should enable the traffic parameters for the PW. PW traffic parameter representations must be the same for all types of PW. If an admission control function resides outside of the PE, e.g. through a BW broker function, then the PW signalling protocol may not need to signal the PW traffic parameters. Existing services such as ATM often associate different traffic parameter values for each direction of a bidirectional connection. If the PW signalling protocol signals PW traffic parameters in-band, it MUST enable separate traffic parameter values to be specified for the forward and reverse direction. Martini, et al. [Page 11] Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004 6.4. Routing MH-PWs MUST provide the following support national and international connections: -i. Inter-Area: for different metro and core routing areas. -ii. Inter-AS: e.g. between national and international ASs. -iii. Inter-provider: for wholesale/transit and for peering services where the two ends of the MH-PW are in different provider networks. In addition, the following general routing requirements apply: -iv. MH-PWs SHOULD be routed across multiple S-PEs without the need to explicitly specify or configure the S-PEs that a PW uses. -v. Manual routing SHOULD be supported to allow diversity for 1+1 protected PWs. 6.5. Signalling The following requirements apply to the signalling of MH-PWs: -i. At a minimum, manual configuration or provisioning of MH-PWs SHOULD be provided. -ii. MH-PWs MAY be set up dynamically end-to-end with a minimal number of OSS touches. -iii. MH-PW signalling MUST provide clear rules and consequent indications for successful/unsucessful setup of a MH-PW. 6.6. Operations and Maintenance (OAM) PWE3 defines an architecture where attachment circuits are connected across a PSN. OAM mechanisms for the attachment cicuits are defined in the specifications for those specific technologies e.g. ITU-T I.610 for ATM. These mechanisms enable, among other things, defects in the network to be detected, localised and diagnosed. They also enable such defect states to clear when a fault recovers. The interworking of OAM mechanisms for SH-PWs between ACs and PWs is defined in [PWE3-OAM]. These enable defect states to be propagated across a PWE3 network following the failure and recovery from faults. OAM mechanisms for MH-PWs MUST provide at least the same capabilities as those for SH-PWs. In addition, it should be possible to support both segment and end-to-end OAM mechanisms for both defect notifications and connectivity verification in order to allow defects Martini, et al. [Page 12] Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004 to be localised in a multi-hop network. That is, PW OAM segments can be U-PE to U-PE, U-PE to S-PE, or S-PE to S-PE. It is desirable to use existing PW OAM mechanisms for MH-PWs. The following requirements apply to OAM for MH-PWs: -i. MH-PW OAM SHOULD be supported end-to-end across the network. -ii. OAM activation/deactivation SHOULD be tied to MH-PW setup/teardown. -iii. The MH-PW client SHOULD support a A Forward Defect Indicator (FDI). -iv. Single ended monitoring SHOULD be supported for both directions of the MH-PW. -v. MH-PW OAM SHOULD support switch over between 1+1 protected LSPs end-to-end. -vi. In-band monitoring SHOULD be provided both end-to-end across the MH-PW, and on a segment (i.e. SH-PW) basis. -vii. To avoid complex OAM interworking at the S-PE, the same PW OAM mechanisms MUST be used on both the ingress and egress sides of an S-PE. -viii. At the U-PE, defect notifications must MUST be propagated between an AC and its associated downstream PW -ix. At the U-PE, if ACs support directional defect notifications, the directionality of the defect notification must be maintained when the notification is mapped to the PW. -x. At the U-PE, defect notifications on a PW must be propagated to the associated downstream AC. -xi. At the S-PE, defect notifications on the upstream segment of PWs must be propagated to the downstream PW segment. -xii. At the S-PE, Upstream and downstream PW segments must use the same PW defect notification mechanisms. -xiii. At the S-PE, defects on an upstream PSN tunnel must be propagated to the downstream PWs that originated on that tunnel. -xiv. The directionality of defect notifications must be maintained across the S-PE. -xv. The S-PE should be able to behave as a segment endpoint for PW OAM mechanisms -xvi. The S-PE should pass end to end and U-PE to U-PE PW OAM messages transparently. Martini, et al. [Page 13] Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004 7. Security Considerations To be written later. 8. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 9. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Martini, et al. [Page 14] Internet Draftdraft-martini-pwe3-MH-PW-requirements-00.txt December 2004 10. Normative References [PWE3-ARCH] "PWE3 Architecture" Bryant, et al., draft-ietf-pwe3-arch-08.txt ( work in progress ), March 2003. [PWE3-OAM] "Pseudo Wire (PW) OAM Message Mapping" Nadeau et al., draft-ietf-pwe3-oam-msg-map-01.txt (work in progress), October 2004 11. Informative References [ITUQ] ITU-T Recommendation Q.933, and Q.922 Specification for Frame Mode Basic call control, ITU Geneva 1995 12. Informative References None 13. Author Information Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112 e-mail: lmartini@cisco.com Matthew Bocci Alcatel Telecom Ltd, Voyager Place Shoppenhangers Road Maidenhead Berks, UK e-mail: matthew.bocci@alcatel.co.uk Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 e-mail: nabil.bitar@verizon.com Martini, et al. [Page 15]