RFC 7625

Architecture of an IP/MPLS Network with Hardened Pipes

📅 published August 2015, from ietf

RFC 7625: Architecture of an IP/MPLS Network with Hardened Pipes 🎀

Okay bestie, this one is an Independent Submission 💅, which means it came in through the independent stream and not the IETF one. It's RFC 7625, and the title is Architecture of an IP/MPLS Network with Hardened Pipes ✨

Here's the title block tea ☕

  • Authors: J. T. Hao, P. Maheshwari, R. Huang, L. Andersson, and M. Chen 🫶
  • Affiliations: J. T. Hao and M. Chen are with Huawei Technologies Co., Ltd, P. Maheshwari is with Bharti Airtel, Ltd., and the R. Huang and L. Andersson entries sit under the same Huawei line in the header 🌸
  • Category: Informational 🦋
  • ISSN: 2070-1721
  • Date: August 2015 📅
  • Obsoletes and updates: the title block doesn't list any, so this doc doesn't obsolete or update anything 🙈

Abstract

Okay so this doc describes an IP/MPLS network whose infrastructure can be split into two or more strata 🧚 For the setup covered here, they split it into two: one for the "Hard Pipes", called the "Hard Pipe Stratum", and one for regular IP/MPLS traffic, called the "Normal IP/MPLS Stratum" 💖

The big idea is the Hard Pipe. It's an MPLS Label Switched Path (LSP) or a pseudowire (PW) with a bandwidth that is guaranteed and can neither be exceeded nor infringed upon. Iconic, honestly 👑

The Hard Pipe stratum doesn't do statistical multiplexing. For the LSPs and PWs set up in there, the bandwidth is guaranteed end to end 🔥

Now the important bit: this doc doesn't specify any new protocol or procedures 🙌 What it does do is explain how the existing MPLS standards implementation got deployed and operated to meet what operators need for their traditional Virtual Leased Line (VLL) services 💅

Status of This Memo

Not gonna lie, this part is the official fine print 📜 This document is not an Internet Standards Track specification. It's published for informational purposes 🦋

It's a contribution to the RFC Series, independently of any other RFC stream 🌈 The RFC Editor chose to publish it at their discretion and makes no statement about its value for implementation or deployment 🤷‍♀️ Documents the RFC Editor approves for publication are not a candidate for any level of Internet Standard, see Section 2 of RFC 5741 📎

For the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc7625 🔗

Copyright (c) 2015 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) as they stand on the publication date. Please actually read these, because they lay out your rights and restrictions with respect to this document 🙏

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   4
   2.  The Stratified Network  . . . . . . . . . . . . . . . . . . .   5
     2.1.  The Physical Network  . . . . . . . . . . . . . . . . . .   6
     2.2.  The Hard Pipe Stratum . . . . . . . . . . . . . . . . . .   6
     2.3.  The Normal IP/MPLS Stratum  . . . . . . . . . . . . . . .   7
     2.4.  Stratum Networks  . . . . . . . . . . . . . . . . . . . .   7
   3.  Configuring the Leased Lines in the Hard Pipe Stratum . . . .   8
   4.  Efficient State Management  . . . . . . . . . . . . . . . . .   9
     4.1.  State in the Forwarding Plane . . . . . . . . . . . . . .   9
     4.2.  State in the NMS/Controller . . . . . . . . . . . . . . .  10
     4.3.  Annotations for Configuring Leased Lines  . . . . . . . .  10
   5.  Setting Up Leased Lines . . . . . . . . . . . . . . . . . . .  12
   6.  Leased Line Protection  . . . . . . . . . . . . . . . . . . .  13
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   8.  Informative References  . . . . . . . . . . . . . . . . . . .  13
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

Here's the map of the whole doc 🗺️ It has sections 1 through 8, plus Acknowledgements and Authors' Addresses at the end ✨

1. Introduction ✨

Okay so IP leased line services, Ethernet Private Line (EPL), and Time-Division Multiplexed (TDM) leased line services are all things operators offer worldwide 🌍

There are customers, like a lot of enterprises, who insist on TDM leased line services 💼 They do this even though the same operators often offer IP leased line services and EPL services at a lower price with a guaranteed bandwidth. Like, why though 💀

Here's the trend: TDM networks (especially Synchronous Digital Hierarchy / Synchronous Optical Network (SDH/SONET)) are carrying less and less traffic, and lots of operators want to shut them down to cut costs 📉

So vendors and operators built and deployed the Hard Pipe service this doc describes 🚀 It's a way to bring leased line service with the same characteristics as TDM leased lines into IP/MPLS networks. Main character energy 👑

Leased lines were the original reason for Hard Pipes, but they are by no means limited to leased line services 🦋 When guaranteed bandwidth is the priority, Virtual Private Wire Services (VPWS), Virtual Private LAN Services (VPLS), L3 Virtual Private Networks (L3VPN), and IP-only Private LAN Services can all be mapped to a tunnel in the Hard Pipe stratum 🎀

EPL and Ethernet Private LAN (EPLAN) are out of scope for this doc, so no spoilers there 🙈

Virtual Leased Line service is the one used in examples all the way through 🌸

The solution that's about to get deployed has an Ethernet infrastructure split into two parallel logical networks, aka two parallel strata 🧚 The first stratum, the Hard Pipe Stratum, doesn't use statistical multiplexing, and bandwidth is guaranteed end to end 💖 The second stratum, the Normal IP/MPLS Stratum, works like a normal IP/MPLS network 🌈 Both strata share the same physical network (the routers and links), but the resource reserved for the Hard Pipe stratum will never be preempted by the Normal IP/MPLS stratum 🫶

The routers handle traffic from one stratum differently from how they handle traffic from the other. This separation in traffic handling is based on support in hardware 🔥

The doc assumes you're already familiar with RFC 3031 [RFC3031] and RFC 5921 [RFC5921] 📚 Bestie, read those first if you haven't 🙏

1.1. Scope

Here's what this doc is trying to do 👀

  • introduce a two strata IP/MPLS network, where one stratum provides capabilities for services that are, from a customer's point of view, functionally identical to TDM-like leased lines; and
  • show how a router differentiates the traffic of the two strata 💅

1.2. Abbreviations

Here's the abbreviation glossary, copied exactly so nothing gets lost in translation 📖

   CC: Continuity Check

   CV: Connection Verification

   L-label: Leased Line label

   LSP: Label Switched Path
   LSR: Label Switching Router

   MPLS-TP: MPLS Transport Profile

   NMS: Network Management System

   OAM: Operations, Administration, and Maintenance

   P: Provider Router

   PE: Provider Edge Router

   PW: Pseudowire

   T-label: Tunnel label

   TDM: Time-Division Multiplexing

   tLDP: Targeted LDP

   VLL: Virtual Leased Line

   VPLS: Virtual Private LAN Service

   VPWS: Virtual Private Wire Service

2. The Stratified Network 🧚

The idea of stratified or strata networks has been around for a while, and it seems to mean different things in different contexts 🤔 The way this doc uses it: you logically assign certain characteristics to part of the network. That special part forms one stratum, and the "remainder" forms a second stratum 💖 The network described here uses a single link-layer technology, which is Ethernet 🌸

A lot of the time, a whole physical interface gets assigned to a single hard stratum, especially when there are many physical links between two nodes 🔗

This doc doesn't go deep on all the network configuration options for Hard Pipe and IP/MPLS strata 🙈 The basic setup is that one Hard Pipe stratum and one IP/MPLS stratum get provisioned 💅

You can also provision more than one Hard Pipe stratum, for example if customers want extra separation for their leased line 👑 Even though leased lines are the main driver for Hard Pipe technology, any service where an operator doesn't want to use statistical multiplexing will benefit from Hard Pipes 🦋

2.1. The Physical Network

Picture a network with 10 routers, where all the links between them are 10G Ethernet, as in Figure 1 🌈 This is the topology the model is built on, and also (with some topology variations) the one used in the first deployment 🚀

           +---+     10G   +---+    10G    +---+   10G    +---+
       +---| B |-----------| C |-----------| D |----------| E |---+
   10G |   +---+           +---+           +---+          +---+   | 10G
       |     |               |               |              |     |
     +---+   |  10G     10G  |          10G  |         10G  |   +---+
   --| F |   |               |               |              |   | G |--
     +---+   |               |               |              |   +---+
       |     |               |               |              |     |
   10G |   +---+           +---+           +---+          +---+   | 10G
       +---| H |-----------| J |-----------| K |----------| L |---+
           +---+      10G  +---+  10G      +---+   10G    +---+

                                 Figure 1

Here's the vocab for the traffic part 📊 The doc uses "traffic matrix" or "estimated traffic matrix" to mean an estimate of how much traffic will flow between the ingress and egress (PE) nodes ✨ That can then be turned into how much bandwidth each link in the Hard Pipe stratum needs 💖

2.2. The Hard Pipe Stratum ✨

okay so, when you want to define a Hard Pipe stratum, you can start from an estimated traffic matrix 💅 and use it to work out how much bandwidth to reserve on the links of the Ethernet link-layer network for the Hard Pipes 🎀

Here's the vibe: the normal traffic gets whatever bandwidth is left over 🫶 So the link-layer network gets split into two logical networks, or two strata. One stratum is for the hardened pipe network, and the other is for the "normal" IP and MPLS traffic. This is shown in Figures 2 and 3.

           +---+    2G     +---+                          +---+
       +---| B |-----------| C |                          | E |---+
    1G |   +---+           +---+                          +---+   |  2G
       |                     |                              |     |
     +---+              2G   |                          1G  |   +---+
   --| F |                   |                              |   | G |--
     +---+                   |                              |   +---+
       |                     |                              |     |
    1G |   +---+           +---+           +---+          +---+   | 2G
       +---| H |-----------| J |-----------| K |----------| L |---+
           +---+      2G   +---+   4G      +---+    4G    +---+

                      Figure 2: The Hard Pipe Stratum

It is worth noting that even though the figures in this document are drawn to show "bandwidth on the link", the only bandwidth information the nodes have is the bandwidth assigned to the Hard Pipe stratum and the Normal IP/MPLS stratum 🌸 All the other information is kept on the NMS/Controller. The NMS/Controller keeps a global bandwidth resource table for the Hard Pipe stratum. 👑

2.3. The Normal IP/MPLS Stratum

Given that the starting point is the physical network in Figure 1 and the Hard Pipe stratum as defined in Figure 2, the Normal IP/MPLS stratum will look like this, as shown in Figure 3 🦋

           +---+      8G   +---+    10G    +---+   10G    +---+
       +---| B |-----------| C |-----------| D |----------| E |---+
    9G |   +---+           +---+           +---+          +---+   |   8G
       |     |               |               |              |     |
     +---+   |  10G      8G  |          10G  |          9G  |   +---+
   --| F |   |               |               |              |   | G |--
     +---+   |               |               |              |   +---+
       |     |               |               |              |     |
    9G |   +---+           +---+           +---+          +---+   |   9G
       +---| H |-----------| J |-----------| K |----------| L |---+
           +---+       8G  +---+   6G      +---+    6G    +---+

                   Figure 3: The Normal IP/MPLS Stratum

2.4. Stratum Networks

In this document, the concept of a stratum network is used to mean basically parallel logical networks with strictly separated resources. 🧚 Traffic sent over one stratum network can not infringe on traffic in the other stratum network. Hard boundary energy. 🔥

In the case described here, all the traffic in the Hard Pipe stratum is MPLS encapsulated. A number of the labels have been set aside, so other applications can't allocate them, and so the routers recognize them as belonging to the Hard Pipe application. 💜

3. Configuring the Leased Lines in the Hard Pipe Stratum

When the strata are provisioned, the IP/MPLS stratum is set up exactly like any other IP/MPLS network. The one small difference between provisioning the Hard Pipe stratum and the IP/MPLS stratum is that no overbooking is done for the Hard Pipe stratum. 🎀

Overbooking and/or congestion in the IP/MPLS stratum can not affect the Hard Pipe stratum. Iconic separation, no notes. 💅

All labels used for the Hard Pipe stratum are "Configured Labels", i.e., labels that are provisioned and reclaimed by management actions. These management actions can be manual actions, or they can come from an NMS/Controller or a centralized controller. For the size of network being deployed, manual configuration is not practical. We are both provisioning and reclaiming a label from an NMS/Controller 😭

  • If an operator wants to set up a leased line, it is first checked whether there is a path available in the Hard Pipe stratum that matches the criteria (e.g., bandwidth) for the requested leased line.
    • If such a path does exist, it is checked whether there is a matching MPLS tunnel available over that path.
      • If such a tunnel exists, it is used to establish the leased line by adding L-labels that form an LSP carried by the tunnel. L-labels are known only by the ingress and egress LSRs. They are local to the endpoints, the same way the label signaled by Targeted LDP (tLDP) is local to the endpoints of a targeted session LSP. (Here, "Targeted LDP" means LDP as defined in RFC 5036 [RFC5036], using Targeted Hello messages.) 🧩

At the same time, the available bandwidth in the Hard Pipe stratum is decremented by the bandwidth needed for the leased line, for every hop across this stratum, in the global resource table (for the Hard Pipe stratum). 📉

  • If such a tunnel does not exist, it can be established so that the leased line can be set up as above. 🛠️
  • If the path does not exist (not enough bandwidth in the Hard Pipe stratum for the leased line), the available bandwidth on the links is checked to see whether the stratum can be expanded to accommodate such a path. 🫣
    • If the Hard Pipe stratum can be expanded, this is done and the tunnel for the leased line is established as described above.

It is likely that other modifications of the Hard Pipe stratum, e.g., consolidating already set up Hard IP tunnels onto existing links so that room for new leased lines is created, may have implications that go well outside the leased line service. It is currently not viewed as a fully automated operation. 🚧

  • If it is not possible to expand the Hard Pipe stratum to accommodate the new path, the set up of the leased line will need to be declined. ❌

Thus, given the existence of a viable Hard Pipe stratum, leased lines are configured in two very simple steps. First, establish a hop-by-hop tunnel (T-labels). Second, configure the leased lines (L-labels). The T-labels need to be configured on both the PE and P routers, while L-labels only need to be configured on the PE routers. ✨

Note that L-labels may be used for normal IP service [RFC3031], BGP/MPLS VPNs [RFC4364], or PWs [RFC3985]. 🌈

4. Efficient State Management ✨

The system as described here generates a very small amount of state, and most of it is kept in the NMS/Controller. 🥹

4.1. State in the Forwarding Plane

The only configured information that is actually kept on the LSRs is:

  • the information needed for the label swapping procedures, i.e., incoming label to outgoing label and port, and whether the label belongs to the set of labels that are set aside for the Hard Pipe stratum tunnels; and
  • the bandwidth available for the Hard Pipe stratum and the Normal IP/MPLS stratum.

4.2. State in the NMS/Controller

The following state needs to be kept in the NMS/Controller:

  • the topology and bandwidth resources available in the Hard Pipe network; see Figure 2.
  • the total and available bandwidth per link in the Hard Pipe network; see Figure 4.
  • the T-label mappings; see Figure 5.
  • the L-label mappings; see Figure 6.
  • the reserved bandwidth, as well as other constraints and the path per L-label.

4.3. Annotations for Configuring Leased Lines

The annotations given below are neither a programming guideline nor an indication of how this architecture could be implemented. 🙈 They are rather an indication of how much data needs to be saved for each stratum and leased line, as well as where this data could be stored.

Considering the Hard Pipe stratum as it has been outlined in Figure 2, there is actually some additional information related to the Hard Pipe stratum that is not shown in the figure.

Looking explicitly at the link between LSR J and K, we find:

           +---+           +---+           +---+          +---+
        ---| H |-----------| J |-----------| K |----------| L |---
           +---+           +---+           +---+          +---+
                                  [4,0]G

                                 Figure 4

The annotation [4,0]G means that 4G is allocated to the stratum on the link between J and K, and of these, 0G has been allocated to a service.

If we were to allocate two tunnel labels from the labels that have been configured to work within the Hard Pipe stratum, the resource view would look like this:

           +---+           +---+           +---+          +---+
        ---| H |-----------| J |-----------| K |----------| L |---
           +---+           +---+           +---+          +---+
                               [4,0]G T1 ,T2

                                 Figure 5

Note that allocating the tunnel labels does not reserve bandwidth for the tunnel from the Hard Pipe stratum. 💖

When the L-labels are assigned, this will consume bandwidth, so we need to keep track of the bandwidth per leased line and the total bandwidth allocated from the Hard Pipe stratum. 📊

The annotation for the link between J and K could look like this:

           +---+           +---+           +---+          +---+
        ---| H |-----------| J |-----------| K |----------| L |---
           +---+           +---+           +---+          +---+
                [4,1.5]G, T1, L1 [.5], L2 [.5], T2, L1 [.5]

                                 Figure 6

The line [4,1.5]G, T1, L1 [.5], L2 [.5], T2, L1 [.5] would be interpreted as follows:

The Hard Pipe stratum link between nodes J and K has 4G bandwidth allocated. Of the total bandwidth, 1.5G is allocated for leased lines.

Tunnel label T1 carries two leased lines, each of 0.5G, and tunnel label T2 carries a third leased line of 0.5G. 🎀

Note that it is not necessary to keep this information in the nodes. It is held within the NMS/Controller. Also, it is not necessary to keep the bandwidth per leased line, but some operations are simplified (e.g., removing a leased line) if this is done. 🌸

5. Setting Up Leased Lines 🎀

okay so let's say an operator wants a leased line of 0.4G from F to G in the Hard Pipe stratum in Figure 2 💖

bestie, there are no constraints here except bandwidth and the ingress and egress PEs, so the shortest path gets picked 🦋 A tunnel gets configured from F to G over nodes F, H, J, K, L, and G, then a Leased Line label (a) is configured on F and G, and the available resources get recalculated ✨

a second leased line of 0.3G between the same PEs is totally easy to set up too 🫶 you just add a new Leased Line label (b) at the ingress and egress PEs 💅

after all that, a view of the Hard Pipe stratum resources (available bandwidth) looks like this 🌈

        +---+    2G     +---+                          +---+
    +---| B |-----------| C |                          | E |---+
 1G |   +---+           +---+                          +---+   |  2G
    |                     |                              |     |
  +---+              2G   |                          1G  |   +---+
--| F |                   |                              |   | G |--
  +---+                   |                              |   +---+
    |                     |                              |     |
.3G |   +---+           +---+           +---+          +---+   | 1.3G
    +---| H |-----------| J |-----------| K |----------| L |---+
        +---+    1.3G   +---+    3.3G   +---+   3.3G   +---+

          Figure 7: The Hard Pipe Stratum after Operations

now here's where it gets spicy 🔥 say the operator wants a NEW leased line that starts at F, ends at G, has 0.4G of bandwidth, and passes through node E 👑 we look at the Hard Pipe stratum (after the first two lines are set up) and compare it to the new criteria, and it goes like this:

  • the existing tunnel can't be used since it doesn't go through E, so a new tunnel needs to be set up 🙈
  • the hop from F to H can't be used either because there isn't enough available bandwidth 💀
  • since no existing tunnels match what's requested, a new tunnel gets set up from F, to B, C, J, K, L, E (to hit the pass-through-E rule), and to G 🧚

then a new L-label (c) to be carried over T2 gets configured on F and G, and the available resources of the Hard Pipe stratum get recalculated 💜

6. Leased Line Protection 🛡️

this leased line service uses MPLS Transport Profile (MPLS-TP) line protection as it's defined in RFC 6378 [RFC6378], and it's updated as specified in RFC 7271 [RFC7271] and RFC 7324 [RFC7324] ✨

the CV and CC run over the tunnels between the Maintenance Entity Group End Points (MEP) at each end, which means the entire tunnel is protected end to end 🫶

in general, all of the MPLS-TP Operations, Administration, and Maintenance (OAM) defined in RFC 6371 [RFC6371] is v applicable 💅

7. Security Considerations 🔐

ngl this section is super important, bestie 😭 the security considerations defined in "Security Framework for MPLS and GMPLS Networks" (RFC 5920 [RFC5920]) and "MPLS Transport Profile (MPLS-TP) Security Framework" (RFC 6941 [RFC6941]) apply to this document 🔥

8. Informative References 📚

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <http://www.rfc-editor.org/info/rfc3031>.

[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, <http://www.rfc-editor.org/info/rfc3985>.

[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.

[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.

[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>.

[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, <http://www.rfc-editor.org/info/rfc5921>.

[RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, DOI 10.17487/RFC6371, September 2011, <http://www.rfc-editor.org/info/rfc6371>.

[RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, October 2011, <http://www.rfc-editor.org/info/rfc6378>.

[RFC6941] Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed., and R. Graveman, Ed., "MPLS Transport Profile (MPLS-TP) Security Framework", RFC 6941, DOI 10.17487/RFC6941, April 2013, <http://www.rfc-editor.org/info/rfc6941>.

[RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H., D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014, <http://www.rfc-editor.org/info/rfc7271>.

[RFC7324] Osborne, E., "Updates to MPLS Transport Profile Linear Protection", RFC 7324, DOI 10.17487/RFC7324, July 2014, <http://www.rfc-editor.org/info/rfc7324>.

Acknowledgements 🙌

the authors want to thank Andy Malis for detailed technical and language review and for valuable comments 💖

Authors' Addresses 🏡

JiangTao Hao
Huawei Technologies Co., Ltd
Q13 Huawei Campus
No. 156 Beiqing Road
Hai-dian District
Beijing  100095
China
Email: haojiangtao@huawei.com


Praveen Maheshwari
Bharti Airtel, Ltd.
Plot No. 16, Udyog Bihar,
Phase IV, Gurgaon - 122015
Haryana
India
Email: Praveen.Maheshwari@in.airtel.com


River Huang
Huawei Technologies Co., Ltd
Q13 Huawei Campus
No. 156 Beiqing Road
Hai-dian District
Beijing  100095
China
Email: river.huang@huawei.com


Loa Andersson
Huawei Technologies Co., Ltd
Stockholm
Sweden
Email: loa@mail01.huawei.com


Mach(Guoyi) Chen
Huawei Technologies Co., Ltd
Q14 Huawei Campus
No. 156 Beiqing Road
Hai-dian District
Beijing  100095
China
Email: mach.chen@huawei.com
📦 where this page comes from