Network Working Group Simon Delord Internet Draft Raymond Key Category: Standard Track Expires: November 2010 Frederic Jounay France Telecom May 19, 2010 Extension to LDP-VPLS for Ethernet Broadcast and Multicast draft-delord-l2vpn-ldp-vpls-broadcast-exten-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 19, 2010. Abstract This document proposes a simple extension to LDP-VPLS to improve bandwidth efficiency for Ethernet broadcast/multicast traffic within a carrier's network. It allows the use of unidirectional point-to-multipoint PseudoWires to minimise payload frame duplication on physical links. Delord et al. Expires November 2010 [Page 1] Internet Draft Ext to LDP-VPLS for Broadcast May 2010 Conventions used in this document 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 [RFC2119]. Table of Contents 1. Introduction...................................................3 2. Problem Statement & Motivation.................................3 2.1. Problem Statement............................................3 2.2. Motivation...................................................3 3. Terminology....................................................4 4. Relevant IETF Technologies for the Proposed Solution...........4 4.1. P2MP LSPs....................................................5 4.2. P2MP PWs.....................................................5 5. Proposed Extension to LDP-VPLS [RFC4762].......................6 5.1. VPLS Reference Model.........................................6 5.2. Choosing PEs to be connected by a P2MP PW for a specific VPLS instance................................................8 5.3. Create and map the P2MP PW to a specific VPLS instance.......8 5.4. Mapping more than one P2MP PW to a specific VPLS instance on a specific root PE........................................8 5.5. Flooding and Forwarding......................................8 5.5.1. Flooding and Forwarding for Ethernet Unknown Unicast.......9 5.6. Address Learning.............................................9 5.7. Loop Free Topology...........................................9 5.8. Hierarchical VPLS............................................9 6. Security Considerations........................................9 7. IANA Considerations...........................................10 8. Acknowledgments...............................................10 9. References....................................................10 9.1. Normative References........................................10 9.2. Informative References......................................10 Appendix A. One Example for Broadcast Video Delivery.............11 Author's Addresses...............................................15 Intellectual Property and Copyright Statements...................15 Delord et al. Expires November 2010 [Page 2] Internet Draft Ext to LDP-VPLS for Broadcast May 2010 1. Introduction This document proposes a simple extension to LDP-VPLS [RFC4762] to improve bandwidth efficiency for Ethernet broadcast/multicast traffic within a carrier's network. This bandwidth improvement is achieved by adding unidirectional point-to-multipoint PseudoWires (P2MP PWs) between selected PEs within a VPLS instance. The addition of these P2MP PWs is on top of the existing full-mesh of point-to-point (P2P) PWs in one VPLS instance. 2. Problem Statement & Motivation 2.1. Problem Statement [RFC5501] provides an in-depth discussion on broadcast/multicast related requirements for VPLS. It highlights two specific issues: - Issue A: replication to non-member site. - Issue B: replication of PWs on shared physical path. If as per [RFC4665] requirement "a L2VPN service SHOULD be agnostic to customer's Layer 3 traffic" and no Layer 3 information is checked for transport, this becomes an impediment to solve Issue A. Issue B on the other hand can still be improved without making use of Layer-3-related information. Issue B may still be considered acceptable when: - Ethernet broadcast/multicast traffic volume is low; and - The number of replications on each outgoing physical interface for a VPLS instance is small (e.g. not many PEs per VPLS instance). However, with more broadcast/multicast applications (e.g. broadcast TV), Ethernet broadcast/multicast traffic volume may increase to a significant level. Assuming HDTV requires 10Mbps per channel, a bundle of 100 channels will require 1Gbps. Furthermore, as MPLS networks expand from the core towards aggregation/access, more PEs may participate in a single VPLS instance. The number of replications on each outgoing physical interface for a VPLS instance is likely to increase. 2.2. Motivation Based on the previous section, it may still be desirable for some carriers to look at improving Issue B without having to look at Layer 3 IP information (Issue A). Delord et al. Expires November 2010 [Page 3] Internet Draft Ext to LDP-VPLS for Broadcast May 2010 One reason for this is that sometimes there is no Layer 3 data to snoop. Another reason may be that some carriers may not be allowed to look above the Layer 2 header, for example there may be regulatory issues with inspecting the customer payload. Also, some carriers may want to avoid Layer 3 snooping simply because of the lack of Layer 3 operational knowledge and the potential complexities associated with it. Another important point is that some carriers may want a manual and selective optimisation process that does not impact network elements not part of it. For example, the bandwidth improvement process may only be required at specific locations in the network where big Ethernet broadcast/multicast talkers exist. Another reason may be that some network elements do not support a specific feature and therefore cannot be selected as part of the optimisation process. Finally, some carriers may also prefer a deterministic process to an entirely automated path selection algorithm that is network driven. The main reason being that operations may become more complicated if they do not control in a completely predictable fashion what is happening on the network. [VPLS-Multicast-BGP] is a solution that looks at solving both Issue A and Issue B. However, [VPLS-Multicast-BGP] proposes that, even for carriers who currently use [RFC4762] without auto-discovery mechanisms, BGP be introduced (section 7). This may also present operational challenges and complexities for some carriers, or this feature may simply not be supported on some of the network elements deployed. This draft therefore explores whether there is a way to improve Layer 2 Ethernet broadcast/multicast bandwidth simply and predictably (i.e. single coverage of receiver membership and Layer 3 IP agnostic) with: - minimal extension to [RFC4762] and without the need to add BGP - minimal impact to existing [RFC4762] deployed networks - operator driven optimisation (i.e. the operator decides where and how the bandwidth improvement should occur). 3. Terminology This document uses terminology described in [RFC4762] and [P2MP-PW-REQ]. 4. Relevant IETF technologies for the proposed solution The proposed solution relies on [RFC4762] existing mechanisms and complements them with extensions (P2MP LSPs and P2MP PWs) already standardised ([RFC4875]) or currently under development by the IETF ([mLDP] and [P2MP-PW-LDP]). Delord et al. Expires November 2010 [Page 4] Internet Draft Ext to LDP-VPLS for Broadcast May 2010 4.1. P2MP LSPs Similarly to what is defined in [RFC4762] where P2P PWs are multiplexed onto P2P LSPs, before the operator can start deploying P2MP PWs, an appropriate underlying layer made of P2MP LPSs needs to be configured (section 3.2 of [P2MP-PW-REQ]). P2MP LSPs are used to minimise packet replication on specific physical links and to allow P routers in an MPLS domain to be transparent to services (e.g. a P Router will join the P2MP PSN tunnel operation but will have no knowledge of the P2MP PWs, same as [RFC4762]). The mapping of the P2MP LSP on top of the physical topology is a key component of the bandwidth enhancement exercise and the operator needs to carefully consider where and how these P2MP LSPs should be deployed (see Appendix A for an example of a possible deployment). Once configured, these P2MP LSPs can then be shared by several P2MP PWs (similar to P2P LSP and P2P PW in [RFC4762]). 4.2. P2MP PWs P2MP PWs can be statically or dynamically configured on top of the P2MP LSPs. This configuration is done on a per PE per VPLS instance basis. In a P2MP PW, the operator decides to connect one Root PE to at least two Leaf PEs (section 3.1 of [P2MP-PW-REQ]). The Root PE is the headend of the P2MP PW (where a big Ethernet broadcast/multicast talker is connected - see example in Appendix A). The Leaf PEs are the endpoints of the P2MP PW (they constitute the receivers where the broadcast/multicast traffic needs to be distributed to). A Root PE may map more than one P2MP PW to a specific VPLS instance. In this case, the Root PE MUST NOT associate a leaf PE to more than one P2MP PW for a specific VPLS instance (this is to avoid a Leaf PE to receive duplicate copies of the same Ethernet frame from different P2MP PWs). P2MP PWs are defined in [P2MP-PW-REQ] and one dynamic solution is defined in [P2MP-PW-LDP]. Delord et al. Expires November 2010 [Page 5] Internet Draft Ext to LDP-VPLS for Broadcast May 2010 5. Proposed Extension to LDP-VPLS [RFC4762] 5.1 VPLS Reference Model Figure 1 shows a topological model (not the physical topology) of a VPLS instance between four PEs with an arbitrary set of ACs attached to each VSI. +---------+ +---------+ | PE1 | | PE2 | | +---+ | | +---+ | | | | | | | +-------AC4---- | | V | | | | V | | | | | | | | | | ----AC1----+--+ | | Ethernet | | +--+----AC5---- | | S +--+-----PW-----+--+ S | | | | | | | | | | ----AC2----+--+ | | | | | | | | I | | | | I | | | | | | Ethernet | | | | ----AC3----+--+ | | PW +-----+--+ | | | +-+-+ | / | +-+-+ | | | \ | / | | | +----+---\+ / +----+----+ | \ / | Ethernet| \/ |Ethernet PW| /\ |PW | / \Ethernet | +----+---/+ \PW +----+----+ |PE3 | / | \ |PE4 | | | +-+-+ | \ | +-+-+ | ----AC6----+--+ | | \ | | +--+----AC8---- | | V | | +----+--+ V | | | | | | | | | | ----AC7----+--+ | | Ethernet | | +--+----AC9---- | | S +--+-----PW-----+--+ S | | | | | | | | | | | | | | | | | | | | I | | | | I | | | | | | | | | | | | | | | | | | | +---+ | | +---+ | | | | | +---------+ +---------+ Figure 1: Reference Diagram for VPLS Delord et al. Expires November 2010 [Page 6] Internet Draft Ext to LDP-VPLS for Broadcast May 2010 Figure 2 shows the proposed extensions to VPLS for Ethernet broadcast and multicast. On top of the topology presented in Figure 2, two P2MP PWs have been added to the existing set of P2P PWs. +---------+ +---------+ | PE1 | | PE2 | | +---+ | | +---+ | | | | | | | +-------AC4---- | | V | | Ethernet | | V | | | | | | P2MP | | | | ----AC1----+--+ | | PW1 | | +--+----AC5---- | | S +--+->--+-->----+--+ S | | | | | | | | | | | ----AC2----+--+ | | | | | | | | | I | | | +->-+--+ I | | | | | | | | | | | | ----AC3----+--+ | | | | | | | | | +---+ | | | | +---+ | | | | | | | +---------+ | | +---------+ | | | | | | | | +---------+ | | +---------+ |PE3 | | | |PE4 | | +---+ | | | | +---+ | ----AC6----+--+ | | +->-----+--+ +--+----AC8---- | | V | | | | | | | | | | | | | | | | ----AC7----+--+ | | | | | +--+----AC9---- | | S +--+->------+->-+--+ S | | | | | | Ethernet | | | | | | | | P2MP | | | | | | I | | PW2 | | I | | | | | | | | | | | | | | | | | | | +---+ | | +---+ | | | | | +---------+ +---------+ Figure 2: Proposed Extensions to VPLS for Ethernet Broadcast/Multicast P2MP PW1 is composed of PE1 as the root PE and PE2 and PE4 as leaf PEs. P2MP PW2 is composed of PE3 as the root PE and PE2 and PE4 as leaf PEs. Delord et al. Expires November 2010 [Page 7] Internet Draft Ext to LDP-VPLS for Broadcast May 2010 Note that for sake of clarity, Figure 2 does not show the full-mesh of P2P PWs presented in Figure 1. Also note that the solution does not require that P2MP PWs be used on all PEs in the VPLS instance, for example there is only a P2P PW between PE1 and PE3 and a P2P PW between PE2 and PE4. 5.2. Choosing PEs for a specific VPLS to be connected by a P2MP PW for a specific VPLS instance This updates section 4.3 of [RFC4762]. VPLS is a full-mesh of P2P PWs and optionally a number of unidirectional P2MP PWs. For each P2MP PW on this VPLS instance: - The operator selects one PE as the Root of the P2MP PW. - A subset or all of the other PEs belonging to the same VPLS instance are chosen to be Leafs of the P2MP PW. - The P2MP PW is unidirectional only (e.g. from the Root PE to all the Leaf PEs connected to it). 5.3. Create and map the P2MP PW to a specific VPLS instance This updates section 4.3 of [RFC4762] and when LDP is used as a dynamic way of signalling P2MP PWs, section 6.1 of [RFC4762] will need to be updated with section 4 of [P2MP-PW-LDP]. P2MP PWs are signalled to demultiplex encapsulated Ethernet frames from multiple VPLS instances that traverse the P2MP transport LSPs. Both the creation and the mapping of P2MP PWs can be done manually or dynamically. An example of dynamic creation/mapping is described in [P2MP-PW-LDP]. 5.4. Mapping more than one P2MP PW to a specific VPLS instance on a specific Root PE The proposed solution allows for a Root PE to map more than one P2MP PW to a specific VPLS instance (see example in Appendix A). However in this case, the Root PE MUST NOT associate a leaf PE to more than one P2MP PW for a specific VPLS instance (this is to avoid a Leaf PE to receive duplicate copies of the same Ethernet frame from different P2MP PWs). 5.5. Flooding and Forwarding This section updates section 4.1 of [RFC4762]. Delord et al. Expires November 2010 [Page 8] Internet Draft Ext to LDP-VPLS for Broadcast May 2010 For flooding of a Ethernet broadcast/multicast frame over PWs to remote PEs participating in the VPLS: - If there is P2MP PW towards a remote PE, the P2P PW associated with this remote PE will not be used. One copy of the frame will be forwarded on the P2MP PW for all the remote PEs associated with it. - If there is no P2MP PW towards a remote PE, the P2P PW associated with this remote PE is used. 5.5.1. Flooding and Forwarding for Ethernet unknown unicast In traditional Ethernet switched networks unknown unicast frames are handled the same way as broadcast and multicast Ethernet traffic (e.g. flooding). Similarly, current VPLS standards also handle unknown unicast traffic by flooding it across all P2P PWs. The purpose of this document is to address Ethernet broadcast and multicast traffic. For Ethernet unknown unicast frames there are two possibilities: - forward the unknown unicast traffic on the P2MP PW, same as for Ethernet broadcast and multicast. - keep the existing mechanism of [RFC4762] and flood the unknown unicast over the P2P PWs. Details on how Ethernet unknown unicast traffic should be handled will be added in a future revision of this document. 5.6. Address Learning This section updates section 4.2 of [RFC4762]. When a Leaf PE receives an Ethernet frame on a P2MP PW it: - First determines the Root PE of the P2MP PW - Then determines the P2P PW associated with that Root PE - Finally, creates a forwarding state in the VPLS instance for the P2P PW associated with the Root PE with a destination MAC address being the same as the source MAC address being learned. 5.7. Loop Free Topology This updates section 4.4 of [RFC4762] Paragraph 2 "must not forward from one PW to another" is applicable to P2MP PW & P2P PW. 5.8. Hierarchical VPLS H-VPLS considerations will be added in a later revision. 6. Security Considerations This section will be added in a future version. Delord et al. Expires November 2010 [Page 9] Internet Draft Ext to LDP-VPLS for Broadcast May 2010 7. IANA Considerations There are no specific IANA considerations in this document. 8. Acknowledgments This section will be added in a future version. 9. References 9.1. Normative References [RFC2119] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997. [RFC4762] Lasserre & Kompella, Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling, January 2007 [P2MP-PW-REQ] F. Jounay, et. al, "Requirements for Point to Multipoint Pseudowire", draft-ietf-pwe3-p2mp-pw-requirements-02.txt, Work in Progress, January 2010. [P2MP-PW-LDP] L. Martini, F. Jounay, et. al, "Signaling Root- Initiated Point-to-Multipoint Pseudowires using LDP", draft-martini-pwe3-p2mp-pw-01.txt, work in Progress, October 2009. [mLDP] I. Minei, K. Kompella, I. Wijnands, B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp-09, Work In Progress, April 2010. [RFC4875] R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs).", rfc4875, May 2007. 9.2. Informative References [RFC5501] Kamite, et al., Requirements for Multicast Support in Virtual Private LAN Services, March 2009 [VPLS-Multicast-BGP] Raggarwa, Kamite & Fang, "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-06.txt, Work in Progress, March 2010 [RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks", RFC 4665, September 2006 Delord et al. Expires November 2010 [Page 10] Internet Draft Ext to LDP-VPLS for Broadcast May 2010 Appendix A. One Example for Broadcast Video Delivery This section describes one deployment scenario in relation to broadcast video delivery and how the proposed solution would work. A.1. Broadcast Video Delivery Topology Figure 3 presents the physical topology of one broadcast video deployment. | | | AC AC AC | | | +---+ +---+ +---+ |PE3| |PE4| |PE5| +---+ +---+ +---+ \ | / \ | / +----+ \ | / +---|PE9 |--AC-- \ | / / +----+ Ethernet +---+ +---+ +---+/ +----+ Broadcast->-AC--|PE1|----------|P1 |--------|P3 |------|PE10|--AC-- Source +---+\ /+---+ +---+\ +----+ \ / | | \ +----+ \ / | | +---|PE11|--AC-- \ / | | +----+ \/ | | /\ | | / \ | | +----+ / \ | | +---|PE12|--AC-- / \ | | / +----+ Ethernet +---+/ \+---+ +---+/ +----+ Broadcast->-AC--|PE2|----------|P2 |--------|P4 |------|PE13|--AC-- Source +---+ +---+ +---+\ +----+ / | \ \ +----+ / | \ +---|PE14|--AC-- / | \ +----+ / | \ +---+ +---+ +---+ |PE6| |PE7| |PE8| +---+ +---+ +---+ | | | AC AC AC | | | Figure 3 - Physical Topology for Broadcast video Delord et al. Expires November 2010 [Page 11] Internet Draft Ext to LDP-VPLS for Broadcast May 2010 Figure 3 is split in three logical components: - The Core network composed of P1, P2, P3 & P4. These 4 network elements are P routers connected in a ring. - The Data Centers. These are a few large PoPs with high resiliency that hold the video content. PE1 & PE2 are located in one Data Center and are dual-homed to the core network. An Ethernet broadcast source is connected to each PE in the Data Center. - The Aggregation network. The Aggregation network is responsible for aggregating last mile technology towards end-users (direct fiber, GPON, DSL, etc.). PE3, PE4, until PE14 are VPLS PE routers, single-homed to the Core network. There are two different video distribution services organised as follows: - VPLS instance-1 (VPLS-1): PE1 is connected to PE3, PE4 ... PE14. - One Ethernet broadcast source is connected to PE1 into VPLS-1. - VPLS instance-2 (VPLS-2): PE2 is connected to PE3, PE4 ... PE14. - One Ethernet broadcast source is connected to PE2 into VPLS-2. A.2. Impact of Physical Topologies on Ethernet Broadcast/Multicast Replication Following the standard VPLS ingress replication mechanism, each time PE1 receives one broadcast frame from the Ethernet broadcast source on VPLS-1, PE1 will replicate 12 times the incoming frame. Similarly, each time PE2 receives one broadcast frame from the Ethernet broadcast source on VPLS-2, PE2 will replicate 12 times the incoming frame. A.3. Proposed Enhancement of Ethernet Broadcast/Multicast The proposed enhancements are done in three steps: - create P2MP LSPs for the infrastructure. These P2MP LSPs are used to carry one or more P2MP PWs. - create unidrectional P2MP PWs by selectively chosing PEs where the optimisation should occur. - forward Ethernet broadcast/multicast frames onto the P2MP PWs where these P2MP PWs have been created. It is up to the network operator to decide how the distribution of the loading on physical link should occur. Two different examples are presented below. Delord et al. Expires November 2010 [Page 12] Internet Draft Ext to LDP-VPLS for Broadcast May 2010 A.3.1 One Possible Enhancement Scenario In this scenario, the operator decides to create the following P2MP LSPs: - PE1->PE3-5 via P1 called LSP1 - PE1->PE6-8 via P2 called LSP2 - PE1->PE9-11 via P3 called LSP3 - PE2->PE3-5 via P1 called LSP4 - PE2->PE6-8 via P2 called LSP5 - PE2->PE9-11 via P3 called LSP6 The operator then creates the following P2MP PWs: - For VPLS-1, PE1->PE3-5 via P2MP PW1 over LSP1 - For VPLS-1, PE1->PE6-8 via P2MP PW2 over LSP2 - For VPLS-1, PE1->PE9-11 via P2MP PW3 over LSP3 - For VPLS-2, PE2->PE3-5 via P2MP PW4 over LSP4 - For VPLS-2, PE2->PE6-8 via P2MP PW5 over LSP5 - For VPLS-2, PE2->PE9-11 via P2MP PW6 over LSP6 There is no P2MP PW between PE1 and PE12, PE13 and PE14. There is no P2MP PW between PE2 and PE12, PE13 and PE14. There are some possible reasons why a P2MP PW may not be available on this part of the network (PE12, PE13 and PE14), for example: - the hardware/software may not allow the support of the required features (P2MP LSPs and/or P2MP PWs). - the operator is currently under a migration phase where only part of the network is migrated at a time. In this case, when PE1 receives one broadcast frame from the Ethernet broadcast source on VPLS-1: - PE1 sends one copy onto P2MP PW1 - PE1 sends one copy onto P2MP PW2 - PE1 sends one copy onto P2MP PW3 - PE1 sends one copy onto the P2P PW towards PE12 - PE1 sends one copy onto the P2P PW towards PE13 - PE1 sends one copy onto the P2P PW towards PE14 PE1 only replicates 6 copies now (this is an improvement from 12 copies if only using P2P PWs). Similar improvement for VPLS-2. Delord et al. Expires November 2010 [Page 13] Internet Draft Ext to LDP-VPLS for Broadcast May 2010 A.3.2. Another Possible Enhancement Scenario In this scenario, the operator decides to create the following two P2MP LSPs: - PE1-> PE3-14 via LSP1: - P1 as a branch towards PE3, PE4, PE5, P2 and P3 - P2 as a branch towards PE6, PE7, PE8 and P4 - P3 as a branch towards PE9, PE10 and PE11 - P4 as a branch towards PE12, PE13 and PE14 - PE2-> PE3-14 via LSP2: - P2 as a branch towards PE6, PE7, PE8, P1 and P4 - P1 as a branch towards PE3, PE4, PE5 and P3 - P3 as a branch towards PE9, PE10 and PE11 - P4 as a branch towards PE12, PE13 and PE14 The operator then creates the following P2MP PWs: - For VPLS-1, PE1-> PE3-14 via P2MP PW1 over LSP1 - For VPLS-2, PE2-> PE3-14 via P2MP PW2 over LSP2 This case improves the P2P PW scenario as PE1 only forwards a single copy of the broadcast frame received from the Ethernet broadcast source on VPLS-1. Similar improvement for VPLS-2. Delord et al. Expires November 2010 [Page 14] Internet Draft Ext to LDP-VPLS for Broadcast May 2010 Author's Addresses Simon Delord Australia Email: simon.delord@gmail.com Raymond Key Australia Email: raymond.key@ieee.org Frederic Jounay France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex France Email: frederic.jounay@orange-ftgroup.com Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Delord et al. Expires November 2010 [Page 15]