summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7025.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7025.txt')
-rw-r--r--doc/rfc/rfc7025.txt675
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc7025.txt b/doc/rfc/rfc7025.txt
new file mode 100644
index 0000000..ea9c1c0
--- /dev/null
+++ b/doc/rfc/rfc7025.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) T. Otani
+Request for Comments: 7025 K. Ogaki
+Category: Informational KDDI
+ISSN: 2070-1721 D. Caviglia
+ Ericsson
+ F. Zhang
+ Huawei Technologies
+ C. Margaria
+ Coriant R&D GmbH
+ September 2013
+
+
+ Requirements for GMPLS Applications of PCE
+
+Abstract
+
+ The initial effort of the PCE (Path Computation Element) WG focused
+ mainly on MPLS. As a next step, this document describes functional
+ requirements for GMPLS applications of PCE.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of 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 candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7025.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Otani, et al. Informational [Page 1]
+
+RFC 7025 Reqs for GMPLS Apps of PCE September 2013
+
+
+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 of PCE . . . . . . . . . . . . . . . . . . 3
+ 2.1. Path Computation in GMPLS Networks . . . . . . . . . . . . 3
+ 2.2. Unnumbered Interface . . . . . . . . . . . . . . . . . . . 5
+ 2.3. Asymmetric Bandwidth Path Computation . . . . . . . . . . 5
+ 3. Requirements for GMPLS Applications of PCE . . . . . . . . . . 6
+ 3.1. Requirements on Path Computation Request . . . . . . . . . 6
+ 3.2. Requirements on Path Computation Reply . . . . . . . . . . 7
+ 3.3. GMPLS PCE Management . . . . . . . . . . . . . . . . . . . 8
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
+ 5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
+ 6.2. Informative References . . . . . . . . . . . . . . . . . . 11
+
+1. Introduction
+
+ The initial effort of the PCE (Path Computation Element) WG focused
+ mainly on solving the path computation problem within a domain or
+ over different domains in MPLS networks. As with MPLS, service
+ providers (SPs) have also come up with requirements for path
+ computation in GMPLS-controlled networks [RFC3945], such as those
+ based on Wavelength Division Multiplexing (WDM), Time Division
+ Multiplexing (TDM), or Ethernet.
+
+ [RFC4655] and [RFC4657] discuss the framework and requirements for
+ PCE on both packet MPLS networks and GMPLS-controlled networks. This
+ document complements those RFCs by providing considerations of GMPLS
+ applications in the intradomain and interdomain networking
+ environments and indicating a set of requirements for the extended
+ definition of PCE-related protocols.
+
+
+
+Otani, et al. Informational [Page 2]
+
+RFC 7025 Reqs for GMPLS Apps of PCE September 2013
+
+
+ Note that the requirements for interlayer and inter-area traffic
+ engineering (TE) described in [RFC6457] and [RFC4927] are outside of
+ the scope of this document.
+
+ 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, Shared Risk Link Group
+ (SRLG) [RFC4202], and so forth, need to be considered to establish
+ GMPLS LSPs. The GMPLS signaling protocol [RFC3473] is designed
+ taking into account bidirectionality, switching type, encoding type,
+ and protection attributes of the TE links spanned by the path, as
+ well as LSP encoding and switching type of the endpoints,
+ appropriately.
+
+ This document provides requirements for GMPLS applications of PCE in
+ support of GMPLS path computation, included are requirements for both
+ intradomain and interdomain environments.
+
+2. GMPLS Applications of PCE
+
+2.1. Path Computation in GMPLS Networks
+
+ Figure 1 depicts a model GMPLS network, consisting of an ingress
+ link, a transit 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, 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 in GMPLS Networks
+
+ For the simplicity in consideration, the 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, including incoming
+ links to the ingress and egress nodes (link2-1 and link3-4) are
+ consistent with switching type of an LSP to be created.
+
+
+
+Otani, et al. Informational [Page 3]
+
+RFC 7025 Reqs for GMPLS Apps of PCE September 2013
+
+
+ (3) Encoding types of all transit links are consistent with the
+ encoding type of 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 GMPLS-based TDM networks are described in this
+ section. In order to simplify the description, this document only
+ discusses the scenario in Synchronous Digital Hierarchy (SDH)
+ networks as an example (see Figure 2). The scenarios in Synchronous
+ Optical Network (SONET) or Optical Transport Network (OTN) are
+ similar.
+
+ N1 N2
+ +-----+ +------+ +------+
+ | |-------| |--------------| | +-------+
+ +-----+ | |---| | | | |
+ A1 +------+ | +------+ | |
+ | | | +-------+
+ | | | PCE
+ | | |
+ | +------+ |
+ | | | |
+ | | |-----| |
+ | +------+ | |
+ | N5 | |
+ | | |
+ +------+ +------+
+ | | | | +-----+
+ | |--------------| |--------| |
+ +------+ +------+ +-----+
+ N3 N4 A2
+
+ Figure 2: A Simple TDM (SDH) Network
+
+ Figure 2 shows a simple TDM (SDH) network topology, where N1, N2, N3,
+ N4, and N5 are all SDH switches; A1 and A2 are client devices (e.g.,
+ Ethernet switches). Assume that one Ethernet service with 100 Mbit/s
+ bandwidth is required from A1 to A2 over this network. The client
+ Ethernet service could be provided by a Virtual Container 4 (VC-4)
+ container from N1 to N4; it could also be provided by three
+ concatenated VC-3s (contiguous or virtual concatenation) from N1 to
+ N4.
+
+
+
+
+Otani, et al. Informational [Page 4]
+
+RFC 7025 Reqs for GMPLS Apps of PCE September 2013
+
+
+ In this scenario, when the ingress node (e.g., N1) receives a client
+ service transmitting request, the type of containers (one VC-4 or
+ three concatenated VC-3s) could be determined by the PCC (Path
+ Computation Client), e.g., N1 or Network Management System (NMS).
+ However, it could also be determined automatically by the PCE 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, and the number of the
+ concatenation in a PCReq (Path Computation Request) message. The PCE
+ should consider those parameters during path computation. The route
+ information (co-routing or diverse routing) should be specified in a
+ PCRep (Path 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, and the PCE should compute a
+ path accordingly.
+
+ Where a GMPLS network consists of interdomain (e.g., inter-AS or
+ inter-area) GMPLS-controlled networks, requirements on the path
+ computation follow [RFC5376] and [RFC4726].
+
+2.2. Unnumbered Interface
+
+ GMPLS supports unnumbered interface IDs as defined in [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)
+ 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
+
+ Per [RFC6387], GMPLS signaling can be used for setting up an
+ asymmetric bandwidth bidirectional LSP. If a PCE is responsible for
+ path computation, it should be capable of computing a path for the
+ bidirectional LSP with asymmetric bandwidth. This means that the PCC
+ should be able to indicate the asymmetric bandwidth requirements in
+ forward and reverse directions in the PCReq message.
+
+
+
+
+
+
+
+
+
+
+
+Otani, et al. Informational [Page 5]
+
+RFC 7025 Reqs for GMPLS Apps of PCE September 2013
+
+
+3. Requirements for GMPLS Applications of PCE
+
+3.1. Requirements on Path Computation Request
+
+ As for path computation in GMPLS-controlled networks as discussed in
+ 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], and RSVP
+ procedures such as explicit label control (ELC), the additional
+ attributes introduced are as follows:
+
+ (1) Switching capability/type: as defined in [RFC3471], [RFC4203],
+ and all current and future values.
+
+ (2) Encoding type: as defined in [RFC3471], [RFC4203], and all
+ current and future values.
+
+ (3) Signal type: as defined in [RFC4606] and all current and future
+ values.
+
+ (4) Concatenation type: In SDH/SONET and OTN, two kinds of
+ concatenation modes are defined: contiguous concatenation,
+ which requires co-routing for each member signal and that all
+ the interfaces along the path support this capability, and
+ virtual concatenation, which allows diverse routing for member
+ signals and requires that only the ingress and egress
+ interfaces support this capability. Note that for the virtual
+ concatenation, it may also specify co-routing or diverse
+ routing. See [RFC4606] and [RFC4328] about concatenation
+ information.
+
+ (5) Concatenation 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): as defined in [RFC4606],
+ [RFC6060], [RFC6002], or [RFC6205].
+
+ (7) 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].
+
+ (9) Link protection type: as defined in [RFC4203].
+
+
+
+
+Otani, et al. Informational [Page 6]
+
+RFC 7025 Reqs for GMPLS Apps of PCE September 2013
+
+
+ (10) Support for unnumbered interfaces: as defined in [RFC3477].
+
+ (11) Support for asymmetric bandwidth requests: as defined in
+ [RFC6387].
+
+ (12) Support for explicit label control during the path computation.
+
+ (13) Support of label restrictions in the requests/responses,
+ similar to RSVP-TE ERO (Explicit Route Object) and XRO (Exclude
+ 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 specified in the PCReq message. Then, the PCE should
+ send a PCRep message, including the computation 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 3.1, the PCE should compute a
+ path accordingly.
+
+ For path computation involving contiguous concatenation, a
+ single route is 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 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, 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. When one ERO represents multiple member
+ signals, the number must be specified.
+
+
+
+
+
+
+
+
+
+Otani, et al. Informational [Page 7]
+
+RFC 7025 Reqs for GMPLS Apps of PCE September 2013
+
+
+ (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, 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 labels that 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, for 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 utilize PCE. (Please refer to [RFC4655]
+ for 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 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].
+
+4. Security Considerations
+
+ PCEP extensions to support GMPLS should be considered under the same
+ security as current PCE work, and this extension will not change the
+ underlying security issues. 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
+
+
+
+
+Otani, et al. Informational [Page 8]
+
+RFC 7025 Reqs for GMPLS Apps of PCE September 2013
+
+
+ specified for securing the TCP connections that underlie PCEP
+ sessions. TCP-AO [RFC5925] has now been published, and PCEP
+ implementations should fully support TCP-AO according to [RFC6952].
+
+5. Acknowledgement
+
+ The authors would like to express thanks to Ramon Casellas, Julien
+ Meuric, Adrian Farrel, Yaron Sheffer, and Shuichi Okamoto for their
+ comments.
+
+6. References
+
+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.
+
+
+
+
+
+
+
+Otani, et al. Informational [Page 9]
+
+RFC 7025 Reqs for GMPLS Apps of PCE September 2013
+
+
+ [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)", 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.
+
+
+
+
+
+
+Otani, et al. Informational [Page 10]
+
+RFC 7025 Reqs for GMPLS Apps of PCE September 2013
+
+
+6.2. Informative References
+
+ [PCE-WSON-REQ]
+ Lee, Y., Bernstein, G., Martensson, J., Takeda, T.,
+ Tsuritani, T., and O. Dios, "PCEP Requirements for WSON
+ Routing and Wavelength Assignment", Work in Progress,
+ June 2013.
+
+ [PCEP-MIB] Koushik, K., Stephan, E., Zhao, Q., King, D., and J.
+ Hardwick, "PCE communication protocol (PCEP) Management
+ Information Base", Work in 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.
+
+
+
+
+
+Otani, et al. Informational [Page 11]
+
+RFC 7025 Reqs for GMPLS Apps of PCE September 2013
+
+
+Authors' Addresses
+
+ Tomohiro Otani
+ KDDI Corporation
+ 2-3-2 Nishi-shinjuku
+ Shinjuku-ku, Tokyo
+ Japan
+ Phone: +81-(3) 3347-6006
+ EMail: tm-otani@kddi.com
+
+
+ Kenichi Ogaki
+ KDDI Corporation
+ 3-10-10 Iidabashi
+ Chiyoda-ku, Tokyo
+ Japan
+ Phone: +81-(3) 6678-0284
+ EMail: ke-oogaki@kddi.com
+
+
+ Diego Caviglia
+ Ericsson
+ 16153 Genova Cornigliano
+ Italy
+ Phone: +390106003736
+ 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
+ Phone: +86-755-28972912
+ EMail: zhangfatai@huawei.com
+
+
+ Cyril Margaria
+ Coriant R&D GmbH
+ St Martin Strasse 76
+ Munich 81541
+ Germany
+ Phone: +49 89 5159 16934
+ EMail: cyril.margaria@coriant.com
+
+
+
+
+
+
+
+Otani, et al. Informational [Page 12]
+