Network Working Group
Internet Engineering Task Force (IETF)                          T. Otani
Internet-Draft
Request for Comments: 7025                                      K. Ogaki
Intended status:
Category: Informational                                             KDDI
Expires: January 22, 2014
ISSN: 2070-1721                                              D. Caviglia
                                                                Ericsson
                                                                F. Zhang
                                                     Huawei Technologies
                                                             C. Margaria
                                                        Coriant R&D GmbH
                                                           July 21,
                                                          September 2013

               Requirements for GMPLS applications Applications of PCE
                  draft-ietf-pce-gmpls-aps-req-09.txt

Abstract

   The initial effort of the PCE (Path computation element) Computation Element) WG was
   mainly focused
   mainly on MPLS.  As a next step, this draft document describes functional
   requirements for GMPLS application applications of PCE.

Status of This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a maximum candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 22, 2014.
   http://www.rfc-editor.org/info/rfc7025.

Copyright Notice

   Copyright (c) 2013 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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  GMPLS applications Applications of PCE  . . . . . . . . . . . . . . . . . .  3
     2.1.  Path computation Computation in GMPLS network Networks . . . . . . . . . . . .  3
     2.2.  Unnumbered Interface . . . . . . . . . . . . . . . . . . .  5
     2.3.  Asymmetric Bandwidth Path Computation  . . . . . . . . . .  5
   3.  Requirements for GMPLS application Applications of PCE . . . . . . . . . .   5  6
     3.1.  Requirements on Path Computation Request . . . . . . . .   5 .  6
     3.2.  Requirements on Path Computation Reply . . . . . . . . .   6 .  7
     3.3.  GMPLS PCE Management . . . . . . . . . . . . . . . . . . .  8
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  9
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1. .  9
     6.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     7.2. .  9
     6.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 11

1.  Introduction

   The initial effort of the PCE (Path computation element) Computation Element) WG was
   mainly focused
   mainly on solving the path computation problem within a domain or
   over different domains in MPLS networks.  As the same case with MPLS, service
   providers (SPs) have also come up with requirements for path
   computation in GMPLS-controlled networks
   [RFC3945] [RFC3945], such as wavelength, TDM-based those
   based on Wavelength Division Multiplexing (WDM), Time Division
   Multiplexing (TDM), or Ethernet-based networks as
   well. Ethernet.

   [RFC4655] and [RFC4657] discuss the framework and requirements for
   PCE on both packet MPLS networks and GMPLS-controlled networks.  This
   document complements these those RFCs by providing some considerations of GMPLS
   applications in the intra-domain intradomain and inter-domain interdomain networking
   environments and indicating a set of requirements for the extended
   definition of PCE-related protocols.

   Note that the requirements for inter-layer interlayer and inter-area traffic
   engineering (TE) described in [RFC6457] and [RFC4927] are outside of
   the scope of this document.

   Constraint-based shortest path first

   Constrained Shortest Path First (CSPF) computation within a domain or
   over domains for signaling GMPLS Label Switched Paths (LSPs) is
   usually more stringent than that of MPLS TE LSPs [RFC4216], because
   the additional constraints, e.g., interface switching capability,
   link encoding, link protection capability, SRLG (Shared
   risk link group) [RFC4202] Shared Risk Link Group
   (SRLG) [RFC4202], and so forth forth, need to be considered to establish
   GMPLS LSPs.  The GMPLS signaling protocol [RFC3473] is designed
   taking into account bi-directionality, bidirectionality, switching type, encoding type type,
   and protection attributes of the TE links spanned by the path, as
   well as LSP encoding and switching type of the end points, endpoints,
   appropriately.

   This document provides requirements for GMPLS applications of PCE in
   support of GMPLS path computation, included are requirements for both
   intra-domain
   intradomain and inter-domain interdomain environments.

2.  GMPLS applications Applications of PCE

2.1.  Path computation Computation in GMPLS network Networks

   Figure 1 depicts a model GMPLS network, consisting of an ingress
   link, a transit link link, as well as an egress link.  We will use this
   model to investigate consistent guidelines for GMPLS path
   computation.  Each link at each interface has its own switching
   capability, encoding type type, and bandwidth.

             Ingress             Transit             Egress
   +-----+   link1-2   +-----+   link2-3   +-----+   link3-4   +-----+
   |Node1|------------>|Node2|------------>|Node3|------------>|Node4|
   |     |<------------|     |<------------|     |<------------|     |
   +-----+   link2-1   +-----+   link3-2   +-----+   link4-3   +-----+

               Figure 1: Path computation Computation in GMPLS networks Networks

   For the simplicity in consideration, the below following basic assumptions
   are made when the LSP is created.

   (1)  Switching capabilities of outgoing links from the ingress and
        egress nodes (link1-2 and link4-3 in Figure 1) are consistent
        with each other.

   (2)  Switching capabilities of all transit links links, including incoming
        links to the ingress and egress nodes (link2-1 and link3-4) are
        consistent with switching type of a an LSP to be created.

   (3) Encoding-types  Encoding types of all transit links are consistent with the
        encoding type of a an LSP to be created.

   GMPLS-controlled networks (e.g., GMPLS-based TDM networks) are
   usually responsible for transmitting data for the client layer.
   These GMPLS-controlled networks can provide different types of
   connections for customer services based on different service
   bandwidth requests.

   The applications and the corresponding additional requirements for
   applying PCE to, for example, to GMPLS-based TDM networks, networks are described in Figure 2. this
   section.  In order to simplify the description, this document
   just only
   discusses the scenario in SDH Synchronous Digital Hierarchy (SDH)
   networks as an example. example (see Figure 2).  The scenarios in SONET Synchronous
   Optical Network (SONET) or OTN Optical Transport Network (OTN) are similar to this scenario.
   similar.

                        N1                    N2
       +-----+       +------+              +------+
       |     |-------|      |--------------|      |       +-------+
       +-----+       |      |---|          |      |       |       |
          A1         +------+   |          +------+       |       |
                        |       |             |           +-------+
                        |       |             |              PCE
                        |       |             |
                        |      +------+       |
                        |      |      |       |
                        |      |      |-----| |
                        |      +------+     | |
                        |         N5        | |
                        |                   | |
                     +------+              +------+
                     |      |              |      |        +-----+
                     |      |--------------|      |--------|     |
                     +------+              +------+        +-----+
                        N3                    N4              A2

                   Figure 2: A simple Simple TDM (SDH) network Network

   Figure 2 shows a simple TDM (SDH) network topology, where N1, N2, N3,
   N4
   N4, and N5 are all SDH switches. switches; A1 and A2 are client devices (e.g.,
   Ethernet switches).  Assume that one Ethernet service with 100M 100 Mbit/s
   bandwidth is required from A1 to A2 over this network.  The client
   Ethernet service could be provided by a VC4 Virtual Container 4 (VC-4)
   container from N1 to N4, and N4; it could also be provided by three
   concatenated VC3
   containers (Contiguous VC-3s (contiguous or Virtual virtual concatenation) from N1 to
   N4.

   In this scenario, when the ingress node (e.g., N1) receives a client
   service transmitting request, the type of containers (one VC4 VC-4 or
   three concatenated VC3) VC-3s) could be determined by the PCC (Path computation
   client) (e.g.,
   Computation Client), e.g., N1 or NMS), but Network Management System (NMS).
   However, it could also be determined automatically by the PCE
   automatically based
   on policy [RFC5394].  If it is determined by the PCC, then the PCC
   should be capable of specifying the ingress node and egress node,
   signal type, the type of the concatenation concatenation, and the number of the
   concatenation in a PCReq (Path computation request) Computation Request) message.  The PCE
   should consider those parameters during path computation.  The route
   information (co-route (co-routing or separated-route) diverse routing) should be specified in a
   PCRep (Path computation reply) Computation Reply) message if path computation is
   performed successfully.

   As described above, the PCC should be capable of specifying TE
   attributes defined in the next section section, and the PCE should compute a
   path accordingly.

   Where a GMPLS network is consisting consists of inter-domain interdomain (e.g., inter-AS or
   inter-area) GMPLS-controlled networks, requirements on the path
   computation follows follow [RFC5376] and [RFC4726].

2.2.  Unnumbered Interface

   GMPLS supports unnumbered interface ID that is IDs as defined in [RFC3477],
   which [RFC3477]; this
   means that the endpoints of the path may be unnumbered.  It should
   also be possible to request a path consisting of the mixture of
   numbered links and unnumbered links, or a P2MP (Point-to-
   multipoint) (Point-to-Multipoint)
   path with different types of endpoints.  Therefore, the PCC should be
   capable of indicating the unnumbered interface ID of the endpoints in
   the PCReq message.

2.3.  Asymmetric Bandwidth Path Computation

   As per

   Per [RFC6387], GMPLS signaling can be used for setting up an
   asymmetric bandwidth bidirectional LSP.  If a PCE is responsible for
   the
   path computation, the PCE it should be capable of computing a path for the
   bidirectional LSP with asymmetric bandwidth.  It  This means that the PCC
   should be able to indicate the asymmetric bandwidth requirements in
   forward and reverse directions in the PCReq message.

3.  Requirements for GMPLS application Applications of PCE

3.1.  Requirements on Path Computation Request

   As for path computation in GMPLS-controlled networks as discussed in
   section
   Section 2, the PCE should appropriately consider the GMPLS TE
   attributes listed below once a PCC or another PCE requests a path
   computation.  The path calculation request message from the PCC or
   the PCE must contain the information specifying appropriate
   attributes.  According to [RFC5440], [PCE-WSON-REQ] [PCE-WSON-REQ], and to RSVP
   procedures like such as explicit label control(ELC),the control (ELC), the additional
   attributes introduced are as follows:

   (1)   Switching capability/type: as defined in [RFC3471], [RFC4203]
   and, [RFC4203],
         and all current and future values.

   (2)   Encoding type: as defined in [RFC3471], [RFC4203] and, [RFC4203], and all
         current and future values.

   (3)   Signal Type: type: as defined in [RFC4606] and, and all current and future
         values.

   (4)   Concatenation Type: type: In SDH/SONET and OTN, two kinds of
         concatenation modes are defined: contiguous concatenation concatenation,
         which requires co-route co-routing for each member signal and requires that all
         the interfaces along the path to support this capability, and
         virtual
   concatenation concatenation, which allows diverse routes routing for the member
         signals and
   only requires that only the ingress and egress
         interfaces to support this capability.  Note that for the virtual
         concatenation, it also may also specify co-routed co-routing or separated-routed. diverse
         routing.  See [RFC4606] and [RFC4328] about concatenation
         information.

   (5)   Concatenation Number: number: Indicates the number of signals that are
         requested to be contiguously or virtually concatenated.  Also
         see [RFC4606] and [RFC4328].

   (6)   Technology-specific label(s) such label(s): as defined in [RFC4606],
         [RFC6060], [RFC6002] [RFC6002], or [RFC6205].

   (7) e2e Path   End-to-End (E2E) path protection type: as defined in [RFC4872],
         e.g., 1+1 protection, 1:1 protection, (pre-planned) rerouting,
         etc.

   (8)   Administrative group: as defined in [RFC3630] [RFC3630].

   (9)   Link Protection protection type: as defined in [RFC4203]

   (10)Support [RFC4203].

   (10)  Support for unnumbered interfaces: as defined in [RFC3477]

   (11)Support [RFC3477].

   (11)  Support for asymmetric bandwidth request: requests: as defined in [RFC6387]

   (12)Support
         [RFC6387].

   (12)  Support for explicit label control during the path computation.

   (13)Support

   (13)  Support of label restrictions in the requests/responses,
   similarly
         similar to RSVP-TE ERO (Explicit route object) Route Object) and XRO (Exclude
   route object)
         Route Object), as defined in [RFC3473] and [RFC4874].

3.2.  Requirements on Path Computation Reply

   As described above, a PCE should compute the path that satisfies the
   constraints which are specified in the PCReq message.  Then  Then, the PCE should
   send a PCRep message message, including the computation result result, to the PCC.
   For a Path Computation Reply message (PCRep) in GMPLS networks, there
   are some additional requirements.  The PCEP (PCE communication
   protocol) PCRep message must be extended to meet the following
   requirements.

   (1)  Path computation with concatenation

        In the case of path computation involving concatenation, when a
        PCE receives the PCReq message specifying the concatenation
        constraints described in section Section 3.1, the PCE should compute a
        path accordingly.

        For path computation involving contiguous concatenation, a
        single route is required required, and all the interfaces along the route
        should support contiguous concatenation capability.  Therefore,
        the PCE should compute a path based on the contiguous
        concatenation capability of each interface and only one ERO which that
        should carry the route information for the response.

        For path computation involving virtual concatenation, only the
        ingress/egress interfaces need to support virtual concatenation
   capability
        capability, and there may be diverse routes for the different
        member signals.  Therefore, multiple EROs may be needed for the
        response.  Each ERO may represent the route of one or multiple
        member signals.
   In the case where  When one ERO represents several member signals among the
   total multiple member
        signals, the number of member signals along the route of
   the ERO must be specified.

   (2)  Label constraint

        In the case that a PCC does not specify the exact label(s) when
        requesting a label-restricted path and the PCE is capable of
        performing the route computation and label assignment
        computation procedure, the PCE needs to be able to specify the
        label of the path in a PCRep message.

        Wavelength restriction is a typical case of label restriction.
        More
   generally in GMPLS-controlled networks generally, label switching and selection constraints may
        apply in GMPLS-controlled networks, and a PCC may request a PCE
        to take label constraint into account and return an ERO
        containing the label or set of label labels that fulfil fulfill the PCC
        request.

   (3)  Roles of the routes

        When a PCC specifies the protection type of an LSP, the PCE
        should compute the working route and the corresponding
        protection route(s).  Therefore, the PCRep should allow to
        distinguish the working (nominal) and the protection routes.
        According to these routes, the RSVP-TE procedure appropriately
        creates both the working and the protection LSPs LSPs, for example example,
        with the ASSOCIATION object [RFC6689].

3.3.  GMPLS PCE Management

   This document does not change any of the management or operational
   details for networks that utilise utilize PCE.  Please  (Please refer to [RFC4655]
   for
   an overview of this scenery. manageability considerations for a PCE-based architecture.)
   However, this document proposes the introduction of several PCEP
   objects and data for the better integration of PCE with GMPLS
   networks.  Those protocol elements will need to be visible in any
   management tools that apply to the PCE, PCC, and PCEP.  That
   includes, but is not limited to, adding appropriate objects to
   existing PCE MIB modules that are used for
   modelling modeling and monitoring
   PCEP deployments [PCEP-MIB].  Ideas for what objects are needed may
   be guided by the relevant GMPLS extensions in GMPLS-TE-STD-MIB [RFC4802]."
   [RFC4802].

4.  Security Considerations

   PCEP extensions to support GMPLS should be considered under the same
   security as current PCE work work, and this extension will not change the
   underlying security issues.  Sec.  Section 10 of [RFC5440] describes the
   list of security considerations in PCEP.  At the time [RFC5440] was
   published, TCP Authentication Option (TCP-AO) had not been fully
   specified for securing the TCP connections that underlie PCEP
   sessions.  TCP-AO [RFC5925] has now been published published, and PCEP
   implementations should fully support TCP-AO according to [RFC6952].

5.  IANA Considerations

   This document has no actions for IANA.

6.  Acknowledgement

   The author authors would like to express the thanks to Ramon Casellas, Julien
   Meuric, Adrian Farrel, Yaron Sheffer Sheffer, and Shuichi Okamoto for their
   comments.

7.

6.  References

7.1.

6.1.  Normative References

   [RFC3471]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Functional Description", RFC 3471,
              January 2003.

   [RFC3473]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

   [RFC3477]  Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
              in Resource ReSerVation Protocol - Traffic Engineering
              (RSVP-TE)", RFC 3477, January 2003.

   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
              (TE) Extensions to OSPF Version 2", RFC 3630,
              September 2003.

   [RFC3945]  Mannie, E., "Generalized Multi-Protocol Label Switching
              (GMPLS) Architecture", RFC 3945, October 2004.

   [RFC4202]  Kompella, K. and Y. Rekhter, "Routing Extensions in
              Support of Generalized Multi-Protocol Label Switching
              (GMPLS)", RFC 4202, October 2005.

   [RFC4203]  Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
              of Generalized Multi-Protocol Label Switching (GMPLS)",
              RFC 4203, October 2005.

   [RFC4328]  Papadimitriou, D., "Generalized Multi-Protocol Label
              Switching (GMPLS) Signaling Extensions for G.709 Optical
              Transport Networks Control", RFC 4328, January 2006.

   [RFC4606]  Mannie, E. and D. Papadimitriou, "Generalized Multi-
              Protocol Label Switching (GMPLS) Extensions for
              Synchronous Optical Network (SONET) and Synchronous
              Digital Hierarchy (SDH) Control", RFC 4606, August 2006.

   [RFC4802]  Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label
              Switching (GMPLS) Traffic Engineering Management
              Information Base", RFC 4802, February 2007.

   [RFC4872]  Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE
              Extensions in Support of End-to-End Generalized Multi-
              Protocol Label Switching (GMPLS) Recovery", RFC 4872,
              May 2007.

   [RFC4927]  Le Roux, J., "Path Computation Element Communication
              Protocol (PCECP) Specific Requirements for Inter-Area MPLS
              and GMPLS Traffic Engineering", RFC 4927, June 2007.

   [RFC5376]  Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS
              Requirements for the Path Computation Element
              Communication Protocol (PCECP)", RFC 5376, November 2008.

   [RFC5440]  Vasseur, JP. and JL. Le Roux, "Path Computation Element
              (PCE) Communication Protocol (PCEP)", RFC 5440,
              March 2009.

   [RFC6002]  Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Data
              Channel Switching Capable (DCSC) and Channel Set Label
              Extensions", RFC 6002, October 2010.

   [RFC6060]  Fedyk, D., Shah, H., Bitar, N., and A. Takacs,
              "Generalized Multiprotocol Label Switching (GMPLS) Control
              of Ethernet Provider Backbone Traffic Engineering (PBB-
              TE)",
              (PBB-TE)", RFC 6060, March 2011.

   [RFC6205]  Otani, T. and D. Li, "Generalized Labels for Lambda-
              Switch-Capable (LSC) Label Switching Routers", RFC 6205,
              March 2011.

   [RFC6387]  Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J.
              Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
              Switched Paths (LSPs)", RFC 6387, September 2011.

   [RFC6689]  Berger, L., "Usage of the RSVP ASSOCIATION Object",
              RFC 6689, July 2012.

7.2.

6.2.  Informative References

   [PCE-WSON-REQ]
              Lee, Y., Bernstein, G., Martensson, J., Takeda, T.,
              Tsuritani, T., and O. de Dios, "PCEP Requirements for WSON
              Routing and Wavelength Assignment", draft-ietf-pce-wson-
              routing-wavelength-09 (work Work in progress), Progress,
              June 2013.

   [PCEP-MIB]
              Koushik, A., Emile, S., K., Stephan, E., Zhao, Q., King, D., and J.
              Hardwick, "PCE communication protocol (PCEP) Management
              Information Base", draft-ietf-pce-pcep-mib-05 (work Work in
              progress), Progress, July 2013.

   [RFC4216]  Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System
              (AS) Traffic Engineering (TE) Requirements", RFC 4216,
              November 2005.

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655, August 2006.

   [RFC4657]  Ash, J. and J. Le Roux, "Path Computation Element (PCE)
              Communication Protocol Generic Requirements", RFC 4657,
              September 2006.

   [RFC4726]  Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for
              Inter-Domain Multiprotocol Label Switching Traffic
              Engineering", RFC 4726, November 2006.

   [RFC4874]  Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes -
              Extension to Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE)", RFC 4874, April 2007.

   [RFC5394]  Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
              "Policy-Enabled Path Computation Framework", RFC 5394,
              December 2008.

   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", RFC 5925, June 2010.

   [RFC6457]  Takeda, T. and A. Farrel, "PCC-PCE Communication and PCE
              Discovery Requirements for Inter-Layer Traffic
              Engineering", RFC 6457, December 2011.

   [RFC6952]  Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
              BGP, LDP, PCEP, and MSDP Issues According to the Keying
              and Authentication for Routing Protocols (KARP) Design
              Guide", RFC 6952, May 2013.

Authors' Addresses

   Tomohiro Otani
   KDDI Corporation
   2-3-2 Nishi-shinjuku
   Shinjuku-ku, Tokyo
   Japan

   Phone: +81-(3) 3347-6006
   Email:
   EMail: tm-otani@kddi.com

   Kenichi Ogaki
   KDDI Corporation
   3-10-10 Iidabashi
   Chiyoda-ku, Tokyo
   Japan

   Phone: +81-(3) 6678-0284
   Email:
   EMail: ke-oogaki@kddi.com

   Diego Caviglia
   Ericsson
   16153 Genova Cornigliano
   Italy

   Phone: +390106003736
   Email:
   EMail: diego.caviglia@ericsson.com

   Fatai Zhang
   Huawei Technologies Co., Ltd.
   F3-5-B R&D Center, Huawei Base
   Bantian, Longgang District, Shenzhen 518129
   P.R.China
   P.R. China

   Phone: +86-755-28972912
   Email:
   EMail: zhangfatai@huawei.com
   Cyril Margaria
   Coriant R&D GmbH
   St Martin Strasse 76
   Munich,
   Munich  81541
   Germany

   Phone: +49 89 5159 16934
   Email:
   EMail: cyril.margaria@coriant.com