Skip to main content

Architecture for Chaining Legacy Layer 4-7 Service Functions
draft-dunbar-sfc-legacy-l4-l7-chain-architecture-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Linda Dunbar , Ron Parker , Ning So , Donald E. Eastlake 3rd
Last updated 2014-01-15
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-dunbar-sfc-legacy-l4-l7-chain-architecture-01
Network working group                                         L. Dunbar
Internet Draft                                                   Huawei
Intended status: Informational                               Ron Parker
Expires: July 2014                                    Affirmed Networks
                                                     I. Smith; S. Majee
                                                            F5 Networks
                                                                  N. So
                                                    Tata Communications
                                                        Donald Eastlake
                                                                 Huawei
                                                       January 15, 2014

       Architecture for Chaining Legacy Layer 4-7 Service Functions
          draft-dunbar-sfc-legacy-l4-l7-chain-architecture-01.txt

Status of this Memo

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

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79. This document may not be modified,
   and derivative works of it may not be created, except to publish it
   as an RFC and to translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on July 15, 2014.

Dunbar, et al.          Expires July 15, 2014                  [Page 1]
Internet-Draft       Chaining Legacy Layer 4-7 SF          January 2014

Copyright Notice

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

Abstract

   This draft analyzes the issues associated with chaining existing
   Layer 4-7 service functions that are not aware of service
   encapsulation layers. This draft also examines the network
   architecture for chaining existing L4-L7 service functions. The
   intent is to identify optimal architecture for flexibly chaining
   existing Layer 4-7 functions to meet various service needs.

Table of Contents

   1. Introduction...................................................3
   2. Conventions used in this document..............................3
   3. Legacy Layer 4-7 Service Functions and Chaining................3
      3.1. Layer 4-7 Service Functions...............................4
      3.2. Service Functions Chaining for Wireless network...........4
      3.3. Proxy Node for Legacy Layer 4-7 Service Functions.........5
   4. Architecture for Chaining Legacy Layer 4-7 Service Functions...6
      4.1. L4-L7 nodes connection to Service Chain Proxy Nodes.......6
      4.2. Traffic Steering at Proxy Nodes...........................7
   5. Challenges of Chaining L4-L7 Service Function..................8
      5.1. Challenge of Multiple Instances of a Service Function.....8
      5.2. Challenges of Layer 4-7 traffic Steering..................9
      5.3. Challenges of Service Chain Classification...............10
   6. Challenge of Service Chain from the Layer 7 Perspective.......11
   7. Conclusion and Recommendation.................................12
   8. Manageability Considerations..................................12
   9. Security Considerations.......................................12
   10. IANA Considerations..........................................12
   11. References...................................................13
      11.1. Normative References....................................13

Dunbar, et al.          Expires July 15, 2014                  [Page 2]
Internet-Draft       Chaining Legacy Layer 4-7 SF          January 2014

      11.2. Informative References..................................13
   12. Acknowledgments..............................................13

1. Introduction

   This draft analyzes the issues associated with chaining existing
   Layer 4-7 service functions that are not aware of service
   encapsulation layers. This draft also examines the network
   architecture for chaining existing L4-L7 service functions. The
   intent is to identify optimal architecture for flexibly chaining
   existing Layer 4-7 functions to meet various service needs.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.

   DPI      Deep Packet Inspection

   FW       Firewall

   Layer 4-7 Service Function: a functional module that performs
   certain action to the packets belonging to an end-to end flow.  The
   action can change the behavior of the packet flow and/or the packets
   themselves, including the packet header and packet payload.
   Exemplary functional modules include Firewall, Deep Packet
   Inspection (DPI), Encryption, Packet De-duplication, Compression,
   TCP Acceleration, NAT, and etc. They are similar to the Service
   Functions defined in [SFC-Problem], except they are not aware of any
   new service header encapsulations. Many of existing Layer 4-7
   service functions fall into this category.

   Layer 4-7 service functions can be instantiated on a standalone
   physical or virtual device, which is called "Service Node" by [SFC-
   Problem]. Layer 4-7 functions can also be embedded in another
   device, such as router/switch or other devices.

3. Legacy Layer 4-7 Service Functions and Chaining

   Legacy Layer 4-7 service functions are the existing service
   functions that may not be aware of any new service encapsulation
   layers or overlay encapsulation layer being discussed in SFC WG.

Dunbar, et al.          Expires July 15, 2014                  [Page 3]
Internet-Draft       Chaining Legacy Layer 4-7 SF          January 2014

3.1. Layer 4-7 Service Functions

   A Layer 4-7 service function performs certain action to the packets
   belonging to an end-to end flow.  The implementation of such service
   function can be either Proxy based or Packet Based, or a hybrid of
   both when more than one function is performed to the same packet
   flow.  Multiple service functions can be instantiated on a single
   service node as defined by [SFC-ARCH], or embedded in a L2/L3
   network node.

   o  Proxy based service functions: these service functions terminate
      original packets, may reassemble multiple packets, reopen a new
      connection, or formulate new packets based on the received
      packets.

   o  Packet based service functions: these service functions maintain
      original packets, i.e. they don't make changes to packets
      traversed through except possibly making changes to metadata
      attached to the packet or the packet's outer header fields.

   Some Layer 4-7 service functions might have intelligence to choose
   different subsequent service functions and pass data packets
   directly to the selected service functions. However, most existing
   Layer 4-7 service functions don't have this capability.

3.2. Service Functions Chaining for Wireless network

   [SFC-MobileNetwork] and [SFC-use-cases] have provided examples of
   service chain in mobile network. In particular, the P-GW/PCEF (per
   3GPP terminology) determines the desired service treatment, i.e.
   desired sequence of service functions, to specific flows based on
   the policies from PCRF.

   Here are some of the issues of service chain in wireless network:

   o  large number of permutations of service functions to be chained
      together

   o  The sequence of services functions applied to selective flows can
      change. New service functions may need to be inserted; existing
      service functions may need to be removed or changed.

Dunbar, et al.          Expires July 15, 2014                  [Page 4]
Internet-Draft       Chaining Legacy Layer 4-7 SF          January 2014

   o  The criteria for applying service functions can take combination
      of application classification, packet headers, and/or other
      factors. For example, the factors that have direct association
      with the packet flow include packet source address, destination
      address, TCP ports. The factors that do not have association with
      the packet flow include user/source location, account status,
      time of day, network condition, and etc.

                       |       Mobile backhaul Network
           +-----+     |          +---+---+
           |PCRF |     |          |Network|
           |     |  < ---- >      |Ctrller|
           +-----+     |          +----+--+
              |        |
              |        |
       +---------+  |  +--------+   +----+      +---------+
   -- >| P-GW    | --> |LB      |---| FW |-->   | Web     | ------>
       |         |  |  |        |   |    |      | Proxy   |
   --->|         |  |  +--------+   +----+      +---------+
   --->|         |  |  +---------+   +----+
   -- >|         | --> |Video    |---| FW |-->  ----------- ------>
       |   [PCEF]|  |  |Optimizer|   |    |
       |         |  |  +---------+   +----+
   --->|         |  |  +--------+   +-----+
   -- >|         | --> |SBC     |---| ACL |-->  ----------- ------>
       |         |  |  |        |   |     |
       +---------+  |  +--------+   +-----+

                 Figure 1 Service Chain for Mobile Network

3.3. Proxy Node for Legacy Layer 4-7 Service Functions

   Section 3.4 of [NSC-Header] describes a scenario that the service
   nodes are not aware of service encapsulation header. The term "proxy
   node" is introduced by [NSC-header] as a gateway to remove and
   insert service layer encapsulation on behalf of service nodes that
   are not aware service layer encapsulation.

   Even though Layer 4-7 Service nodes can be instantiated anywhere in
   the network, it is not uncommon to have more than one service
   functions located in close vicinity with a service chain proxy node,
   or one to two links away. The following figure depicts typical
   network architecture for chaining those Layer 4-7 service nodes that
   are not aware of service layer encapsulation.

Dunbar, et al.          Expires July 15, 2014                  [Page 5]
Internet-Draft       Chaining Legacy Layer 4-7 SF          January 2014

                        |1  -----   |n        |21   ---- |2m
                    +---+---+   +---+---+   +-+---+   +--+-----+
                    | Ad    |   |Content|   |Video|   |Security|
                    |Insert |   | Opt   |   | Opt |   | App    |
                    +---+---+   +---+---+   +--+--+   +--+--+--+
                        :           :          :         :  :
                        :           :          :         :  :
                         \         /            \       /
       +--------------+   +--------+             +---------+
   -- >| Chain        | ->| Proxy  |--------->   | Proxy   | ---->
       |classification|   |Node-1  |             | Node-i  |
       +--------------+   +----+---+             +----+--+-+
                                 |--                  |  |
                                 V                    +--->
                            +--------+
                            | Proxy  |
                            |   -j   |----->
                            +--------+

            Figure 2 Chaining existing Layer 4-7 service nodes

   When there are more than one service functions or nodes located in
   the vicinity of a service chain "proxy node", the Proxy node needs
   to steer designated traffic to the designated service functions.

   The service chain proxy nodes can be standalone devices, or can be
   embedded with routers or switches in the network. Overlay tunnels
   are expected to connect the "proxy nodes" together.

4. Architecture for Chaining Legacy Layer 4-7 Service Functions

4.1. L4-L7 nodes connection to Service Chain Proxy Nodes

   L4-L7 Service nodes can be connected to Service Chain proxy nodes in
   various ways. The topology could be bump in a wire or one armed
   topology.

   o  A service function can be embedded in a Service Chain proxy node
      (i.e. embedded in a router or a switch).

      In this case, the service function doesn't need an address to
      receive data packets. The forwarding entity can send packets that
      meet the steering criteria directly to the service function
      regardless of the destination addresses in the packets. The
      Service function always sends the processed packets back to the
      forwarding entity regardless of the destination addresses in the
      packets.

Dunbar, et al.          Expires July 15, 2014                  [Page 6]
Internet-Draft       Chaining Legacy Layer 4-7 SF          January 2014

   o  A service node can be one hop away from a service chain proxy
      node

      The one hop between the Service Chain proxy node and the service
      node can be a physical link (e.g. Ethernet link). Under this
      scenario, there would be a Link Header, i.e. an outer MAC header,
      added to the data packets that meet the steering criteria.

      The one hop link can be a transparent link, i.e. no link address
      is added to the data packets on the link between the Service
      Chain proxy node and Service node. I.e. the service nodes are set
      to promiscuous mode that can apply treatment to data frames
      arrived at the ingress port regardless of the Link Destination
      address. This scenario is considered the same as a service
      function being embedded in the Service Chain proxy node.

   o  A service node can be multiple hops away, such as when a service
      is deployed in an on-net or private *aaS offering.

4.2. Traffic Steering at Proxy Nodes

   Some service chains may require steering to Layer 4-7 functions
   based on Layer 2 or 3 fields of the data packets. Some service
   chains may require steering traffic to Layer 4-7 service functions
   based on some higher layer fields in the data packets, i.e. Layer 4
   to Layer 7 fields.

   The policies for Proxy Nodes to steer traffic to its connected
   service functions or service function instances can change. Those
   policies can be carried by the "metadata" introduced by [SFC-ARCH],
   or combination of data packets' header fields, metadata, and other
   factors. Those steering policies can be dynamically updated by
   network controller(s).

   There are multiple types of traffic steering:

   o  Fixed header based forwarding: traffic steering based on header
      fields that have fixed position in the data packets:

       o  Forwarding based on Layer 2-3 header fields, such as MAC or
          IP Destination Address, Source Addresses, MPLS label, VLAN
          ID, or combination of multiple Layer 2-3 header fields.

       o  Forwarding based on Layer 4 header (TCP or UDP).

       o  QoS header based forwarding.

Dunbar, et al.          Expires July 15, 2014                  [Page 7]
Internet-Draft       Chaining Legacy Layer 4-7 SF          January 2014

   o  Layer 7 based forwarding: traffic steering (or forwarding) based
      on the payload (L7) of data packets.

      Multiple data packets may carry some meaningful data, like one
      HTTP message. Under this scenario, multiple data packets have to
      be examined before meaningful data can be extracted for making
      Layer 7 based forwarding decision.

   o  Metadata based steering:  traffic steering (or forwarding) based
      on the identity of the initiating user, the UE model or type, the
      site name or FQDN, or network conditions (congestion,
      utilization, etc.).

      However those metadata might not necessarily be carried by each
      data packet due to extended bits required that can cause high
      probability of packet fragmentation. Those metadata can be
      dynamically passed down to steering nodes in some forms of
      steering policies from network controller(s).

5. Challenges of Chaining L4-L7 Service Function

   From user's perspective, the service chain is a sequence of service
   functions, such as Chain#1 {s1, s4, s6}, Chain#2{s4, s7} applied to
   a data flow. A flow is loosely used in this document to refer to a
   selective of packets that meet certain criteria, e.g. IP flows, 5
   tuple based flow or a HTTP transaction. Some users might not care at
   which points in the network the selected flow is steered to those
   service functions as long as the sequence of the service functions
   is correct.

5.1. Challenge of Multiple Instances of a Service Function

   From the traffic flow perspective, a Service Chain guarantees that
   specific data flows go through a specific sequence of service
   functions' instances.

   For each service function, there could be multiple instances, with
   some in close proximity and others far apart being connected by
   different service chain proxy nodes. With Network Function
   Virtualization (NFV) initiative, more and more service functions
   have virtualized instances instantiated on servers or virtual
   machines. NFV imposes higher chance of service function instances
   being changed due failure or load shifting.

   When instances change, the management system or the Service Chain
   controller can update the steering policies to proxy nodes,
   dynamically, to steer the selected flows to different instances.

Dunbar, et al.          Expires July 15, 2014                  [Page 8]
Internet-Draft       Chaining Legacy Layer 4-7 SF          January 2014

   Alternatively, a proxy node may employ a method for selecting a
   particular service instance for a flow or group of related flows.
   The selection could be stateful like basic round-robin, connection
   count etc. or stateless e.g hash based or random.

                          |
                 +---+------+                +---+---+   +--+-----+
                 |controller|                |Service|   |Service |
                 |          |                |Func-1 |   |Func- m |
                 +---+------+                +----+--+   +--+--+--+
                    /    \   \                    :         /
                   /      \   +---------------+   :        /
                  /        \                   \  :       /
           +-----------+     +--------+         +---------+
       -- >| Service   | --> |Proxy   |------>  | Proxy   | ------>
           |   node    |     |Node-1  |         | Node-2  |
           +-----------+     +--------+         +---------+

        Figure 3 Service Chain from Traffic Steering Point of View

   Some service functions make changes to data packets, such as NAT
   changing the address fields. If any of those fields are used in
   traffic steering along the service chain, the criteria can be
   different before and after those the service functions.

5.2. Challenges of Layer 4-7 traffic Steering

   Very often the criteria for steering flows to service functions are
   based on higher layer headers, such as TCP header, HTTP header, etc.

   Most of deployed switches/routers are very efficient in forwarding
   packets based on Layer 2 or Layer 3 headers, such as MAC/IP
   destination addresses, or VLAN/MPLS labels but have limited capacity
   for forwarding data packets based on higher layer header. As of
   today, differentiating data packets based on higher layer headers
   depends on ACLs (Access Control List field matching) or DPI, both of
   which are relatively expensive and extensive use of such facilities
   may limit the bandwidth of switches/routers.

   The Service Chain classification node introduced by [Boucadair-
   framework] and [SFC-ARCH] can alleviate the workload on large number
   of nodes in the network, including service chain proxy nodes, from
   steer traffic based on higher layer fields.

Dunbar, et al.          Expires July 15, 2014                  [Page 9]
Internet-Draft       Chaining Legacy Layer 4-7 SF          January 2014

                         |1  -----   |n        |21   ---- |2m
                   +---+---+   +---+---+   +-+---+   +--+-----+
                   | Ad    |   |Content|   |Video|   |Security|
                   |Insert |   | Opt   |   | Opt |   | App    |
                   +---+---+   +---+---+   +--+--+   +--+--+--+
                       :           :          :         :  :
                       :           :          :         :  :
                        \         /            \       /
      +--------------+   +--------+             +---------+
   - >| Chain        | ->| Proxy  |-------->    | Proxy   | --->
      |classification|   |Node-1  |             | Node-2  |
      +--------------+   +--------+             +---------+

                 Figure 4 Service Chain Marking At Ingress

   A Service Chain Classification node can associate a unique Service
   Chain Label (e.g. Layer 2 or 3 Label) to the packets in the flow.
   Such a Layer 2 or 3 Label makes it easier for subsequent nodes along
   the flow path to steer the flow to the service functions specified
   by the flow's service chain.

   The network elements that have the Service Chain Classification
   Function are most likely network ingress edge nodes, such as
   Wireless Packet Gateway, Broadband Network Gateways, Cell Site
   Gateways, etc.

   In some situations, like service chain for wireless subscribers,
   many flows (i.e. subscribers) have common service chain
   requirements. Under those situations, the Service Chain
   classification Functional can mark multiple flows with the same
   service chain requirement using the same Layer 2 or 3 Label, which
   effectively aggregates those flows into one service chain.

   For service chains that are shared by a great number of flows, they
   can be pre-provisioned. For example, if VLAN ID=10 is the service
   chain that need to traverse "Service-1" at Proxy Node #1 and
   "Service-3" at Proxy Node #2, the steering policy for VLAN ID=10 can
   be dynamically changed by controllers.

5.3. Challenges of Service Chain Classification

   The policy for associating flows with their service chains can be
   complicated and could be dynamic due to different behavior
   associated with chains, balancing load among multiple instances for
   one service function, and instance failure.

Dunbar, et al.          Expires July 15, 2014                 [Page 10]
Internet-Draft       Chaining Legacy Layer 4-7 SF          January 2014

   For a chain of {FW, Header_enrichment, smart_node, Video_opt,
   Parental Control}, the video optimizer really needs to work on the
   response path. It may also use completely different encapsulation
   e.g. ICAP for example. There could be Smart-Node to further classify
   a particular part of the flow and bypass something, say the
   video_opt. Therefore, the classification done by the service chain
   classification nodes at the network entrance can't completely
   dictate the exact sequence of service functions.

   The Service Chain Classification node can encounter flows that don't
   match with any policies. There is a default policy that applies all
   statutorily required policies to the unknown flows.

   Multiple flows can share one service chain. The criteria to select
   flows to be associated with their service chain could be different.
   For example, for one service chain "A" shared by Flow X, Y, Z:

   o  Criteria for Flow X to the Service Chain "A" are TCP port

   o  Criteria for Flow Y to the Service Chain "A" are Destination
      Address

   o  Criteria for Flow Z to the Service Chain "A" are MPLS label.

6. Challenge of Service Chain from the Layer 7 Perspective

   From the Layer 7 perspective, the service chain can be much more
   complex. As shown in the figure below, the service functions to be
   chained can depend on the HTTP message request and reply. The
   service chain classification nodes may have to examine the whole
   HTTP message to determine the specific sequence of service functions
   for the flows. The HTTP message might have to be extracted from
   multiple data packets. Sometimes, the logic to steer traffic to
   chain of service functions might depend on the data retrieved from a
   database based on messages constructed from packets. The decision
   may depend on the HTTP response rather than the request, or it may
   depend on a particular sequence of request-response messages. The
   message handler may also alter the Layer 7 service chain based on
   hints or modification done by previous service function. HTTP based
   service function may insert HTTP header to add further criterion for
   service selection in the next round of classification.

Dunbar, et al.          Expires July 15, 2014                 [Page 11]
Internet-Draft       Chaining Legacy Layer 4-7 SF          January 2014

                        +----------+
       Client --------->(  Layer 7 )--------->  Internet
              <---------(  Message )<---------
                        (  Handler )
                --------(          )--------________
               /        +----------+        \
              /           /       \          \
             |1          |2        |3         |4
         +---+---+   +---+---+   +-+---+   +--+-----+
         | Ad    |   |Content|   |Video|   |Security|
         |Insert |   | Opt   |   | Opt |   | App    |
         +---+---+   +---+---+   +--+--+   +--+--+--+
             :           :          :         :  :
             :           :          :         :  :

                 Figure 5 Layer 7 Service Chain Complexity

7. Conclusion and Recommendation

   There are many service functions being deployed already in the
   network. Many of them are not capable to adapt to new service chain
   encapsulation layer.

   This document provides architecture framework for chaining those
   Layer 4-7 service functions that are not aware of new service layer
   encapsulation.

8. Manageability Considerations

   There currently exists no single management methodology to control
   the L2-4 packet-based forwarding device, the L4-7 service delivery
   device, and the L7+ application server.  Such unified management of
   configuration state is required for service function chaining to be
   a practical solution.

9. Security Considerations

   TBD

10. IANA Considerations

   This document requires no IANA actions. RFC Editor: Please remove
   this section before publication.

Dunbar, et al.          Expires July 15, 2014                 [Page 12]
Internet-Draft       Chaining Legacy Layer 4-7 SF          January 2014

11. References

11.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

11.2. Informative References

   [Boucadair-framework] M. Boucadair, et al, "Differentiated Service
             Function Chaining Framework", < draft-boucadair-service-
             chaining-framework-00>; Aug 2013

   [SFC-Problem]  P. Quinn, et al, "Service Function Chaining Problem
             statement", <draft-quinn-sfc-problem-statement-02>, Dec 9,
             2013

   [SFC-Arch]  P. Quinn, et al, "Service Function Chaining (SFC)
             Architecture", < draft-quinn-nsc-arch-00>, Sept 2013

   [NSH-Header]   P. Quinn, et al, "Network Service Header", < draft-
             quinn-nsh-01>, July 12, 2013

   [SC-MobileNetwork] W. Haeffner, N. Leymann, "Network Based Services
             in Mobile Network", IETF87 Berlin, July 29 2013

   [Application-SDN] J. Giacomonni, "Application Layer SDN", Layer 123
             ONF Presentation, Singapore, June 2013

   [SC-Use-Case]  Liu, et, al., "Service Chaining Use Cases", < draft-
             liu-service-chaining-use-cases-00>, Sept, 2013

12. Acknowledgments

   This draft has merged some sections from
   http://datatracker.ietf.org/doc/draft-parker-sfc-chain-to-path/.

   This draft has taken input from "Application Layer SDN" presentation
   given by John Giacomoni of F5 at Layer 123 conference. Thanks to
   Huang Shi Bi and Li Hong Yu for the valuable comments and
   suggestions.

   This document was prepared using 2-Word-v2.0.template.dot.

Dunbar, et al.          Expires July 15, 2014                 [Page 13]
Internet-Draft       Chaining Legacy Layer 4-7 SF          January 2014

Authors' Addresses

   Linda Dunbar
   Huawei Technologies
   1700 Alma Drive, Suite 500
   Plano, TX 75075, USA
   Phone: (469) 277 5840
   Email: ldunbar@huawei.com

   Ron Parker
   Affirmed Networks
   Acton, MA 01720
   USA
   Email: ron_parker@affirmednetworks.com

   Ian Smith
   F5 Networks
   Email: I.Smith@F5.com

   Sumandra Majee
   F5 Networks
   Email: S.Majee@F5.com

   Ning So
   Tata Communications
   Email: Ning.So@tatacommunications.com

   Donald Eastlake
   Huawei Technologies
   155 Beaver Street
   Milford, MA 01757 USA
   Phone: 1-508-333-2270
   Email: d3e3e3@gmail.com

Dunbar, et al.          Expires July 15, 2014                 [Page 14]