Network Working Group G. Cauchie Internet-Draft France Telecom - Orange Intended status: Standards Track October 17, 2010 Expires: April 20, 2011 A method to monitor MPLS label mappings draft-cauchie-opsawg-monitoring-mpls-label-mapping-00 Abstract Because one MPLS label only identifies one single flow on a link between two MPLS routers, information related to one MPLS label is exchanged only between (physically and logically) neighbour routers. In other words, MPLS label have a link-local significance on which two neighbour routers have previously agreed on. It is therefore not a trivial task for a network operator to know where a flow is going as it implies to retreive the MPLS labels mappings on each hops in order to get a complete view of end-to-end LSP paths. This taks is even harder when it comes to get the MPLS label mappings over time in a purpose of monitoring and/or troubleshooting network services. This document thus defines a new method to monitor MPLS label mappings that collects and stores MPLS labels mapping information so as to offer to one IP/MPLS network operator a reliable and clear view of its network LSPs end-to-end establishment over time while minimising the impact on network convergence and router CPU. Requirements Language 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 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." G. Cauchie Expires April 20, 2011 [Page 1] Internet-Draft Monitoring MPLS Label Mappings October 2010 This Internet-Draft will expire on April 20, 2011. 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. G. Cauchie Expires April 20, 2011 [Page 2] Internet-Draft Monitoring MPLS Label Mappings October 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Principles . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Interests . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Procedures and format . . . . . . . . . . . . . . . . . . . . 7 3.1. connection establishment . . . . . . . . . . . . . . . . . 7 3.2. Messages for label mapping description . . . . . . . . . . 7 3.2.1. Messages format . . . . . . . . . . . . . . . . . . . 7 3.2.2. Message examples . . . . . . . . . . . . . . . . . . . 9 3.2.3. Message compression . . . . . . . . . . . . . . . . . 16 3.3. Information sending . . . . . . . . . . . . . . . . . . . 16 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 7. Normative References . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 G. Cauchie Expires April 20, 2011 [Page 3] Internet-Draft Monitoring MPLS Label Mappings October 2010 1. Introduction Since many years now, MPLS tunnels (defined in [RFC3031]) are more and more used in IP networks to carry many services (native IP, VPNs,etc.) and offer them isolation, Fast Reroute potential and/or differentiated quality of service. To ease MPLS tunnels (ie MPLS LSPs) establishment and rerouting, protocols to dynamically distribute MPLS labels mapping (like LDP [RFC5036] and RSVP-TE [RFC3209]) have been developped and improved over the years. These protocols succeded in this task so that today network operators are managing hundreds, thousands or more LSPs in their network. While the establishment of MPLS LSPs became so easy for operators, monitoring and furthermore troubleshooting MPLS LSPs events didn't quite follow the same path. Because of its local significant labels and its "link-local scope" information exchange, MPLS LSPs monitoring and troubleshooting can only be fairly accomplished if an operator has a complete view of events occuring on each MPLS routers. In the last few years, many mechanisms have been designed to give operators a better real-time view of their MPLS LSPs. It is now possible to quickly and accurately localize the routers causing the MPLS LSP down event and start working on resolving the issue. But things gets complicated, not to say unfeasible, when one customer complaigns for a problem that occured the day before for instance. Having a MPLS labels mappings monitoring system that can offer the knowledge of all the label mappings in use over time and that keeps from loading the routers in the busy CPU periods will help one MPLS network operator to gain important information to monitor and troubleshoot its MPLS network while minimizing the impact on the routers which can advertise the new mappings after making sure rerouting is done. Furthermore, by knowing the location and duration of labels mapping disruption, one operator can easily report the potential damages and take a look to the guilty routers to find the disruption cause, increasing its troubleshooting performance. The rest of the docuemnt is structured as follows: Section 2 sets the global architecture where all MPLS routers participate in sending the proper label mapping information to one or more servers, Section 3 defines the procedures and message encoding in order to achieve interoperability between the servers and the routers. 2. Architecture G. Cauchie Expires April 20, 2011 [Page 4] Internet-Draft Monitoring MPLS Label Mappings October 2010 2.1. Principles As per the MPLS Architecture [RFC3031] definition, one packet or frame entering the MPLS world is first bound to a label. This binding is placed in the FTN (FEC-to-NHLFE) table of one LER (Label Edge Router). Then, this labeled packet is switched on a hop-by-hop basis as specified in the ILM (Incoming Label Map) table of each LSR routers along the path until the last hop. Monitoring one MPLS LSP thus requires to have the FTN and ILM knowledge at each LSP hop. This MPLS label monitoring method then consists in gathering the FTN and ILM information (called from now on in this document as "label mappings information") of each MPLS routers in an IP/MPLS network. These label mappings information are then sent by all MPLS routers in the network to one or more servers (for potential redundancy or load sharing) for storage in order to obtain the complete view of the way unlabeled and labeled packets are managed in the network MPLS environment. Information is also required to be timestamped by the routers and updated over time to reflect the changes and the moment of these changes in the network (for troubleshooting or other network studies). Information is encoded in XML format [W3C.REC-xml]. Advantages of XML are its flexibility for easy evolutions, its self-documented scheme and the set of tools already alvailable on the server side to compute the set of received information. Disadvantage of XML is its bulk size, that's why information shall be compressed before it is sent by the router over the wire (as approached in [I-D.cheng-grow-bgp-xml]). Compressed XML information is transported over TCP in order to ensure correct and complete exchanges. One requirement of this method is to have no impact on the network convergence performance. As one incentive for this method is to perform MPLS LSP monitoring, one may find this requirement in contradiction with the incentive. Monitoring is indeed important to trigger human reaction. But since we have routing protocols to dynamically reroute the traffic in an order of magnitude far better than human reactions, it is essential for Service providers to prioritize routing convergence before sending the monitoring information about label mappings. That is why label mappings information must be sent in moments when the router is having a low CPU usage. Timestamping the label mappings information with the time when route convergence occured is again important as the time when the information is sent over to the server may always be done later than the time when changes have occured in the network. G. Cauchie Expires April 20, 2011 [Page 5] Internet-Draft Monitoring MPLS Label Mappings October 2010 Another requirement of this method is to be independant from the protocol used to distribute the mappings. As a consequence, description of label mappings do not presuppose that either LDP [RFC5036] or RSVP-TE [RFC3209]) protocols were used. This indifference works also for point-to-point and point-to-multipoint LSPs, SPF-computed routed LSPs and explicitely routed LSPs, etc. What the server receiveing the label mappings information does of these information is beyond the scope of this document. 2.2. Interests In the last few years, new OAM mechanisms (such as VCCV) have been designed to give operators a better real-time view of their MPLS LSPs. These tools are really satisfying for investigations when a problem is occuring but can not be used to understand where a failure had happened in the past. Interest of the monitoring solution defined in this document is not only to have a representation of the MPLS LSPs in place in the network but also to gain an history of active label mappings in order to be able to get back in time and see what mappings were used at a specific time to get a better understanding of the environment and localize where (and for how long) the problem occured and how many times it has occured (for service availability calculation). Already known and deployed protocols could also be used to get the label mappings, like SNMP [RFC1157] for instance. However, SNMP presents some disadvantages compared to this solution. On one hand, when using 'SNMP gets', one network operator has to poll all routers at regular intervals. These intervals must then be as short as as possible in order not to miss any changes, implying a huge sollicitation of all routers sending their complete mappings. And as the experience shows that mappings are pretty stable over time, it is at the end a big waste of consumed bandwidth and CPU ressources in comparison to the fact of only sending changes when they occur. Furthermore, shortening the intervals is not stricly sufficient to ensure a knwoledge of the precise changes time. And finally, queries can reach routers at rerouting times, thus adding load to the router and impact the network convergence. On the other hand, when using SNMP traps, one network operator loses the reliability offered by TCP, for instance when micro routing loops are appearing in the network and packets are lost on the way. At the end, this solution is gathering all the pros of existing solutions by giving a complete view of the MPLS LSPs like with 'SNMP gets', react to changes like 'SNMP traps', provide precise timing information like syslog messages, and transmit the information in a reliable and standardized/common way that is independent of one's G. Cauchie Expires April 20, 2011 [Page 6] Internet-Draft Monitoring MPLS Label Mappings October 2010 implementation specificities and protocol usage. Furthermore, the exchanged data is not penalizing the network convergence performance and the use of XML provides an easy mechanism for evolutions without requiring changes in the specification. 3. Procedures and format 3.1. connection establishment For security reason, the router is responsible of the connection initiation. Hence, one router MUST NOT accept TCP SYN messages on TCP ports one implementor may assign to label mappings monitoring. It is RECOMMENDED for the connection to remain constantly open. Having a permanently open connection allows to easily and quickly detect router failure as a server receiving a TCP SYN will automatically know that some restart happened on the router, but on the other side, a server has to maintain many connections in parallel over which generally no messages are sent or received. Having a connection open on demand has the advantage of unloading the server with hundreds of parallel connections. However, mechanisms must be defined to differentiate a router restart from a classical change advertisement and to take the according actions. Once TCP connection is established, the router MUST send all its label mappings to the server. The timestamp used SHALL be set to the time when the TCP connection opens. 3.2. Messages for label mapping description 3.2.1. Messages format To perform an MPLS label mapping monitoring, one router must send its MPLS forwarding entries to the server. As previously said, [RFC3031] defines that MPLS forwarding entries are fed by the entries from the FTN and the ILM tables. Some implementations today are mixing information from the two tables into one single table usually called "label bindings" table. But at the end, the mandatory information needed to perform the label mappings monitoring, that MUST be advertised by routers to the server, are: o router ID o FEC o ingress label value G. Cauchie Expires April 20, 2011 [Page 7] Internet-Draft Monitoring MPLS Label Mappings October 2010 o forwarding operation o timestamp Router ID is either the unique IPv4 or IPv6 address identifying the router in the network. The FEC identifies the flow to be mapped into the LSP tunnel. It can thus be either IP prefixes for legacy IP over MPLS LSPs, a so-called VRF-id for a L3VPN [RFC4364] service or a so-called VSI-id/AC-id respectively for a VPLS/VPWS [RFC4664] service. A VRF-id is a tupple containing both the loopback address of the PE router and the Route- Distinguisher (RD) in order to identify the targeted VRF inside a VPN. A VSI-id (or AC-id) is a tupple containing both the loopback address of the PE router and the Pseudo-Wire ID (PWid) in order to identify the targeted VSI (or AC) inside a VPN. FEC information can be to unknown for cases like LSR where an LSP is explicitely routed LSP or manually configured. The ingress label value is the label value of incoming labelled packets the router is ready to forward. A "-1" value of the ingress label indicates a FTN entry for untagged packets or frame entering the MPLS environment. The ingress label value field can contain multiple values if, for instance, a label space per interface is in use. This is why a label value MUST be associated with an origin value. The origin value can be: o 'untagged' value for packets or frame entering the MPLS environment, o 'service' value for packets or frame that just received the inner label corresponding to the destinated VRF, VSI or AC o 'platform' value if the label value was received on a session with a per platform label space use, o the upstream router Router_ID if the label value was received on a session with a per interface label space use The forwarding operation is a tupple of 3 different information. First is the "label operation", which is the set of push, pop or swap actions the router will perform for ingress packets that fall into the FEC conditions or for ingress labelled packets whose label value is equal to the ingress label value. Other possible values of the "label operation field" is "none" so as to indicate that the router entry for the ingress label value is no more in use, and "replicate" in the case of P2MP LSPs with multiple branches. Second is the "egress label value", which is the label value resulting from the G. Cauchie Expires April 20, 2011 [Page 8] Internet-Draft Monitoring MPLS Label Mappings October 2010 label operation action. The egress label value "-1" is to be used when the ingress label value entry is no more in use or when the label operation is "pop". Third is the "next-hop information", which can be: o the next-hop IP address to where the label is to be forwarded, o 'FEC', indicating that the packet/frame is to be delivered outside the MPLS environment, o 'recursive', indicating that the label at the top of the label stack will be check by the router for forwarding Timestamp is the time when the label mapping decribe by the previous items became active. This timestamp SHALL be encoded in a unix format with the addition of microseconds information. Examples of messages in different MPLS context are given in the next section. Then optional information can be added to the label mapping information set. For instance, SNMP indexes, neighbour identity and/or LSP encoding types can be added to the set of mandatory information. Use of options is left to implementors. 3.2.2. Message examples This section illutrates the message format describe in the previous section in three different context. 3.2.2.1. L3VPN context with Penultimate-hop popping (PHP) The network configuration for this context is described in Figure 1. The label mapping information describe the LSP used in order for VRF_1 to reach the VRF_2 as a whole (ie one prefix per VRF configuration is used) and the LSP used as a transport between routers R1 and R3 (ie the outter label). This context does not assume any other LSPs used as transport, uses only per platfrom label space, and makes router R2 use Penultimate-hop Popping. G. Cauchie Expires April 20, 2011 [Page 9] Internet-Draft Monitoring MPLS Label Mappings October 2010 | |(VRF_1) ------ | R1 | (Push inner label 13 + Push outter label 12) ------ | | | ------ | R2 | (Pop label 12) ------ | | | ------ | R3 | (Pop label 13) ------ |(VRF_2 announcing @A with Route distinguisher RD2) | | Figure 1: L3VPN service with PHP In this context, the following message will be generated to describe. Router R1 will generate two messages: 1. one message for the inner label * Router ID = @R1 * FEC = [ type = VRF_ID ; Loopback IP address = @R3 ; RD = RD2 ] * Ingress label value = [ (value = -1 ; origin = 'untagged')] * Forwarding operation = [ operation = push ; label = 13 ; next- hop = recursive] * Timestamp = 2010/10/10 15:30:01.674842 2. one message for the outter label * Router ID = @R1 * FEC = [ type = IP ; IP prefix = @R3/32 ] * Ingress label value = [ (value = 13 ; origin = 'service')] G. Cauchie Expires April 20, 2011 [Page 10] Internet-Draft Monitoring MPLS Label Mappings October 2010 * Forwarding operation = [ operation = push ; label = 12 ; next- hop = @R2/32] * Timestamp = 2010/10/10 15:30:01.674842 . Router R2 will generate one message: 1. one message for the outter label * Router ID = @R2 * FEC = [ type = IP ; IP prefix = @R3/32 ] * Ingress label value = [ (value = 12 ; origin = 'platform')] * Forwarding operation = [ operation = swap ; label = 3 ; next- hop = @R3/32] * Timestamp = 2010/10/10 15:30:01.674842 . Router R3 will generate one message: 1. one message for the inner label * Router ID = @R3 * FEC = [ type = VRF_ID ; Loopback IP address = @R3 ; RD = RD2 ] * Ingress label value = [ (value = 13 ; origin = 'platform')] * Forwarding operation = [ operation = pop ; label = -1 ; next- hop = 'FEC'] * Timestamp = 2010/10/10 15:30:01.674842 . 3.2.2.2. VPWS context The network configuration for this context is described in Figure 2. The label mapping information describe the LSP used in order for AC_1 to reach the AC_2 (identified with the inner label) and the LSP used as a transport between routers R1 and R3 (identified with the outter label). This context does not assume any other LSPs used as G. Cauchie Expires April 20, 2011 [Page 11] Internet-Draft Monitoring MPLS Label Mappings October 2010 transport, uses only per platfrom label space, and does not have any Penultimate-hop Popping. | |(AC_1 linked to PW-ID pw1) ------ | R1 | (Push inner label 13 + Push outter label 12) ------ | | | ------ | R2 | (Swap label 12 to label 23) ------ | | | ------ | R3 | (Pop label 23 + Pop label 13) ------ |(AC_2 linked to PW-ID pw1) | | Figure 2: VPWS service with no PHP In this context, the following message will be generated to describe. Router R1 will generate two messages: 1. one message for the inner label * Router ID = @R1 * FEC = [ type = AC_ID ; Loopback IP address = @R3 ; PW_ID = pw1 ] * Ingress label value = [ (value = -1 ; origin = 'untagged')] * Forwarding operation = [ operation = push ; label = 13 ; next- hop = recursive] * Timestamp = 2010/10/10 15:30:01.674842 2. one message for the outter label * Router ID = @R1 G. Cauchie Expires April 20, 2011 [Page 12] Internet-Draft Monitoring MPLS Label Mappings October 2010 * FEC = [ type = IP ; IP prefix = @R3/32 ] * Ingress label value = [ (value = 13 ; origin = 'service')] * Forwarding operation = [ operation = push ; label = 12 ; next- hop = @R2/32] * Timestamp = 2010/10/10 15:30:01.674842 . Router R2 will generate one message: 1. one message for the outter label * Router ID = @R2 * FEC = [ type = IP ; IP prefix = @R3/32 ] * Ingress label value = [ (value = 12 ; origin = 'platform')] * Forwarding operation = [ operation = swap ; label = 23 ; next- hop = @R3/32] * Timestamp = 2010/10/10 15:30:01.674842 . Router R3 will generate two messages: 1. one message for the outter label * Router ID = @R3 * FEC = [ type = IP ; IP prefix = @R3/32 ] * Ingress label value = [ (value = 23 ; origin = 'platform')] * Forwarding operation = [ operation = pop ; label = -1 ; next- hop = recursive] * Timestamp = 2010/10/10 15:30:01.674842 2. one message for the inner label * Router ID = @R3 G. Cauchie Expires April 20, 2011 [Page 13] Internet-Draft Monitoring MPLS Label Mappings October 2010 * FEC = [ type = AC_ID ; Loopback IP address = @R3 ; PW_ID = pw1 ] * Ingress label value = [ (value = 13 ; origin = 'platform')] * Forwarding operation = [ operation = pop ; label = -1 ; next- hop = 'FEC'] * Timestamp = 2010/10/10 15:30:01.674842 . 3.2.2.3. LSR with multiple branches of a P2MP LSP The network configuration for this context is described in Figure 3. The label mapping information describe the different branches of the P2MP LSP in order for packets to be forwarded from the head-end to the different leaves. This context assumes only one LSPs used as transport, uses only per interface label space, and does not have any Penultimate-hop Popping. | |(tree head-end using IPv4 multicast address @m) ------ | R1 | (Push inner label 13 + Push outter label 12) ------ | | | ------ | R2 | (Replicate to R3 with swap label 12 to label 23 ------ + to R4 with swap label 12 to label 24) | | ----- ----- | | ------ ------ (Pop label 23) | R3 | | R4 | (Pop label 24) ------ ------ (leaf_1) | | (leaf_2) | | | | Figure 3: P2MP LSP In this context, the following message will be generated to describe. Router R1 will generate one message: G. Cauchie Expires April 20, 2011 [Page 14] Internet-Draft Monitoring MPLS Label Mappings October 2010 1. one message for the outter label * Router ID = @R1 * FEC = [ type = IP ; IP prefix = @m/32 ] * Ingress label value = [ (value = -1 ; origin = 'untagged')] * Forwarding operation = [ operation = push ; label = 12 ; next- hop = @R2/32] * Timestamp = 2010/10/10 15:30:01.674842 . Router R2 will generate one message: 1. one message for the outter label * Router ID = @R2 * FEC = [ type = IP ; IP prefix = @m/32 ] (in case of explicitely routed tunnels, the FEC type will be 'unknown') * Ingress label value = [ (value = 12 ; origin = '@R1')] * Forwarding operation = [ operation = replicate ; [ (label = 23 ; next-hop = @R3/32) ; (label = 24 ; next-hop = @R4/32) ] ] * Timestamp = 2010/10/10 15:30:01.674842 . Router R3 will generate one message: 1. one message for the outter label * Router ID = @R3 * FEC = [ type = IP ; IP prefix = @m/32 ] (in case of explicitely routed tunnels, the FEC type will be 'unknown') * Ingress label value = [ (value = 23 ; origin = '@R2')] * Forwarding operation = [ operation = pop ; label = -1 ; next- hop = 'FEC' ] G. Cauchie Expires April 20, 2011 [Page 15] Internet-Draft Monitoring MPLS Label Mappings October 2010 * Timestamp = 2010/10/10 15:30:01.674842 . Router R4 will generate one message: 1. one message for the outter label * Router ID = @R4 * FEC = [ type = IP ; IP prefix = @m/32 ] (in case of explicitely routed tunnels, the FEC type will be 'unknown') * Ingress label value = [ (value = 24 ; origin = '@R2')] * Forwarding operation = [ operation = pop ; label = -1 ; next- hop = 'FEC' ] * Timestamp = 2010/10/10 15:30:01.674842 . 3.2.2.4. IP over MPLS context with ECMP TODO 3.2.3. Message compression TODO 3.3. Information sending TODO 4. IANA Considerations TODO 5. Security Considerations This method is not supposed to introduce new security concerns on the routers for two reasons. Firstly, because the router must not accept incoming connection from any parties for this topic, and secondly because even if a third-party is performing a Man-in-the-middle attack, the router must not accept incoming packets except TCP ACK packets. G. Cauchie Expires April 20, 2011 [Page 16] Internet-Draft Monitoring MPLS Label Mappings October 2010 Other concerns may impact the server, receiving the TCP connection establishment from the routers and storing the label mappings information. But this is out the scope of the document. 6. Acknowledgements Special thanks to Kireeti Kompella and Cengiz Alaettinoglu for their useful comments and feedbacks on this topic. 7. Normative References [I-D.cheng-grow-bgp-xml] Cheng, P., Yan, H., Burnett, K., Massey, D., and L. Zhang, "BGP routing information in XML format", draft-cheng-grow-bgp-xml-00 (work in progress), February 2009. [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [W3C.REC-xml] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC- xml, October 2000, . G. Cauchie Expires April 20, 2011 [Page 17] Internet-Draft Monitoring MPLS Label Mappings October 2010 Author's Address Gregory CAUCHIE France Telecom - Orange 38-40 avenue du General LECLERC Issy-les-Moulineaux 92130 FRANCE Email: gregory.cauchie@orange-ftgroup.com G. Cauchie Expires April 20, 2011 [Page 18]