Skip to main content

Framework for Interface to Network Security Functions
draft-merged-i2nsf-framework-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 "Replaced".
Authors Linda Dunbar , Diego Lopez , Xiaojun Zhuang , Joe Parrott , Ramki Krishnan , Seetharama Rao Durbha
Last updated 2015-06-03
Replaced by draft-ietf-i2nsf-problem-and-use-cases, draft-ietf-i2nsf-framework, RFC 8329
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-merged-i2nsf-framework-01
Network Working Group                                         L. Dunbar
Internet Draft                                                   Huawei
Intended status: Informational                                 D. Lopez
Expires: December 2015                                       Telefonica
                                                               X. Zhuang
                                                            China Mobile
                                                              J. Parrott
                                                                      BT
                                                             R Krishnan
                                                                 Brocade
                                                               S. Durbha
                                                               CableLabs

                                                           June 3, 2015

           Framework for Interface to Network Security Functions
                    draft-merged-i2nsf-framework-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

xxx, et al.            Expires December 3, 2015                [Page 1]
Internet-Draft              I2NSF Framework                   June 2015

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

   This Internet-Draft will expire on December 3, 2015.

Copyright Notice

   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) 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 document describes the framework for Interface to Network
   Security Functions and defines a reference model along with
   functional components.

Table of Contents

   1. Introduction...................................................3
   2. Conventions used in this document..............................3
   3. Reference Models in Managing NSFs..............................4
      3.1. NSF Facing Interface......................................5
      3.2. Client Facing Interface...................................5
      3.3. Vendor Facing Interface...................................5
      3.4. The network connecting the Security Controller and NSFs...6
      3.5. Interface to vNSFs........................................7
   4. Flow-based NSF Capability Characterization.....................8
   5. Security Policies Provisioning to NSFs........................11
      5.1. Capability Layer Provisioning and Monitoring.............11
      5.2. Service Layer Security Policy............................12
   6. Capability Negotiation........................................13

xxx, et al.            Expires December 3, 2015                [Page 2]
Internet-Draft              I2NSF Framework                   June 2015

   7. Types of I2NSF clients........................................14
   8. Manageability Considerations..................................14
   9. Security Considerations.......................................14
   10. IANA Considerations..........................................15
   11. References...................................................15
      11.1. Normative References....................................15
      11.2. Informative References..................................15
   12. Acknowledgments..............................................16

1. Introduction

   This document describes the framework for Interface to Network
   Security Functions (I2NSF) and defines a reference model along with
   functional components for I2NSF. It also describes how I2NSF
   facilitates SDN/NFV control, while avoiding potential constraints
   which could limit NSFs internal functions.

   The I2NSF use cases ([I2NSF-ACCESS], [I2NSF-DC] and [I2NSF-Mobile])
   call for standard interfaces for customers to control and monitor
   security functions hosted and managed by service providers.

   [I2NSF-Problem] describes the motivation and the problem space for
   Interface to Network Security Functions.

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.

   BSS:  Business Support System

   Controller: used interchangeably with Service Provider Security
               Controller or management system throughout this
               document.

   FW:   Firewall

xxx, et al.            Expires December 3, 2015                [Page 3]
Internet-Draft              I2NSF Framework                   June 2015

   IDS:  Intrusion Detection System

   IPS:  Intrusion Protection System

   NSF:  Network Security Functions, defined by [I2NSF-Problem]

   OSS:  Operation Support System

   vNSF: refers to NSF being instantiated on Virtual Machines.

3. Reference Models in Managing NSFs

   As described by [Packet-based-NSF], NSFs management can be generally
   grouped into three types: Configuration, Signaling, and
   Provisioning. This document only focuses on the framework of
   provisioning and monitoring of the flow-based NSFs.

   The following figure shows various interfaces for managing the
   provisioning & monitoring aspects of flow-based NSFs.

                   Client/AppGW
                         |
                         |  Client Facing Interface
                   +-----+---------------+
                   |Service Provider mgmt|              +-------------+
                   | Security Controller | < -------- > | Vendor      |
                   +---------------------+ Vendor Facing|  Sys        |
                                   |         Interface  +-------------+
                                   |
                                   | NSF Facing Interface
                                   |
        +------------------------------------------------+
        |                                                |
        |                                                |
   +------+         +------+             +------+       +------+
   + NSF-1+ ------- + NSF-n+             +NSF-1 + ----- +NSF-m +  . . .
   +------+         +------+             +------+       +------+

   Vendor A                                       Vendor B

                         Figure 1: Multiple Interfaces

xxx, et al.            Expires December 3, 2015                [Page 4]
Internet-Draft              I2NSF Framework                   June 2015

3.1. NSF Facing Interface

     This is the interface between the Service Provider's management
     system (or Security Controller) and the NSFs that are selected to
     enforce the desired network security. This interface is called
     Capability Interface in the I2NSF context.

3.2. Client Facing Interface

     This interface is for clients or Application Gateway to express
     and monitor security policies for their specific flows. The Client
     Facing interface is called Server Layer Interface in the I2NSF
     context.

     A single client layer policy may need multiple NSFs collectively
     together to achieve the enforcement.

3.3. Vendor Facing Interface

     Even though security functions come in variety of form factors and
     have different features, [Packet-based-NSF] advocates that the
     flow based NSFs can be categorized by

       - Subject - Match values based on packet data Packet header or
          Packet payload,
       - Object - Match values based on context, e.g. State, time,
          geo-location, etc.,
       - Action- Egress processing, such as Invoke signaling; Packet
          forwarding and/or transformation; Possibility for SDN/NFV
          integration, and
       - Functional Profile - E.g. IPS:<Profile>, signature file,
          Anti-virus file, URL filtering file, etc. Integrated and one-
          pass checks on the content of packets.

xxx, et al.            Expires December 3, 2015                [Page 5]
Internet-Draft              I2NSF Framework                   June 2015

     The functional profile or signature file is one of the key
     properties that determine the effectiveness of the NSF, and is
     mostly vendor specific today.

     When service providers have multiple types of security functions
     provided by different vendors, it is necessary to have an
     interface for vendors to register their NSFs indicating what level
     can be provisioned or monitored for each of the categories listed
     above.

     The Registration Interface can be static or dynamic. When NSFs are
     upgraded, vendors need to notify the service provider management
     system or controller of the updated capabilities.

3.4. The network connecting the Security Controller and NSFs

     Most NSFs are not directly attached to the Security Controller; it
     is especially true when NSFs are distributed across the network.
     The network that connects the Security Controller with the NSFs
     can be the same network that carry the data traffic, or can be a
     dedicated network for management purpose only. Either case, packet
     loss could happen due to failure, congestion, or other reasons.

     Therefore, the transport mechanism used to carry the control
     messages and monitoring information should provide reliable
     message delivery.  Transport redundancy mechanisms such as
     Multipath TCP (MPTCP) [MPTCP] and the Stream Control Transmission
     Protocol (SCTP) [RFC3286] will need to be evaluated for
     applicability.  Latency requirements for control message delivery
     must also be evaluated.

     The connection between Security Controller and NSFs could be:

     - Closed environments where there is only one administrative
       domain.  More permissive access controls and lighter validation
       is needed inside the domain because of the protected
       environment.

xxx, et al.            Expires December 3, 2015                [Page 6]
Internet-Draft              I2NSF Framework                   June 2015

     - Open environments where some NSFs (virtual or physical) can be
       hosted in external administrative domains or reached via
       external network domains.  Then more restrictive security
       controls are required over the I2NSF interface.  The information
       over the I2NSF interfaces must use trusted channels, such as
       TLS, SASL, or the combination of the two.

     Over the Open Environment, I2NSF needs to provide the identity
     frameworks and federations models for authentication and
     Authorization.

3.5. Interface to vNSFs

     Even though there is no difference between virtual network
     security functions (vNSF) and physical NSFs from policy
     provisioning perspective, there are some unique characteristics in
     interfacing to the vNSFs:

     - There could be multiple instantiations of one single NSF being
       distributed across network. When different instantiations are
       visible to the Security Controller, different policies may be
       applied to different instantiations of one single NSF.
     - When multiple instantiations of one single NSF appear as one
       single entity to the Security Controller, the policy
       provisioning has to be sent to the NSF's sub-controller, which
       in turn disseminate the polices to the corresponding
       instantiations of the NSF, as shown in the figure below. See
       Figure 2 below.
     - Policies to one vNSF may need to be retrieved and move to
       another vNSF of the same type when client flows are moved from
       one vNSF to another.
     - Multiple vNSFs may share the same physical platform
     - There may be scenarios where multiple vNSFs collectively perform
       the security policies needed.

xxx, et al.            Expires December 3, 2015                [Page 7]
Internet-Draft              I2NSF Framework                   June 2015

                          +------------------------+
                          | Security Controller    |
                          +------------------------+
                                   ^        ^
                                   |        |
                       +-----------+        +------------+
                       |                                 |
                       v                                 v
    + - - - - - - - - - - - - - - - +  + - - - - - - - - - - - - - - - +
    |  NSF-A  +--------------+      |  |  NSF-B  +--------------+      |
    |         |Sub Controller|      |  |         |sub Controller|      |
    |         +--------------+      |  |         +--------------+      |
    | + - - - - - - - - - - - - - + |  | + - - - - - - - - - - - - - + |
    | |+---------+     +---------+| |  | |+---------+     +---------+| |
    | || NSF-A#1 | ... |  NSF-A#n|| |  | ||  NSF-B#1| ... |  NSF-B#m|| |
    | |+---------+     +---------+| |  | |+---------+     +---------+| |
    | |         NSF-A cluster     | |  | |          NSF-B cluster    | |
    | + - - - - - - - - - - - - - + |  | + - - - - - - - - - - - - - + |
    + - - - - - - - - - - - - - - - +  + - - - - - - - - - - - - - - - +

                Figure 2: Cluster of NSF Instantiations Management

4. Flow-based NSF Capability Characterization

   There are many types of flow-based NSFs. To prevent constraints on
   NSF vendors' creativity and innovation, [Packet-Based-NSF]
   recommends the flow-based NSF interfaces to be designed from the
   paradigm of processing packets on the network. Flow-based NSFs
   ultimately are packet-processing engines that inspect packets
   traversing networks, either directly or in context to sessions to
   which the packet is associated.

   Flow-based NSFs differ in the depth of packet header or payload they
   can inspect, the various session/context states they can maintain,
   the specific profiles and the actions they can apply. Accordingly,
   the NSF capabilities are characterized by the level of packet
   processing and context that a NSF supports, the profiles and the
   actions that the NSF can apply.

   Vendors can register their NSFs using the Subject-Object-Action-
   Function categories described by [Packet-based-NSF], with detailed
   specification of each category as shown in the table below:

xxx, et al.            Expires December 3, 2015                [Page 8]
Internet-Draft              I2NSF Framework                   June 2015

     +-----------------------------------------------------------+
     |         Subject Capability Index                          |
     +---------------+-------------------------------------------+
     | Layer 2       | Layer 2 header fields:                    |
     | Header        | Source/Destination/s-VID/c-VID/EtherType/.|
     |               |                                           |
     |---------------+-------------------------------------------+
     | Layer 3       | Layer  header fields:                     |
     |               |            protocol                       |
     | IPv4 Header   |            port                           |
     |               |            src port                       |
     |               |            dscp                           |
     |               |            length                         |
     |               |            flags                          |
     |               |            ttl                            |
     |               |                                           |
     | IPv6 Header   |                                           |
     |               |            addr                           |
     |               |            protocol/nh                    |
     |               |            src port                       |
     |               |            length                         |
     |               |            traffic class                  |
     |               |            hop limit                      |
     |               |            flow label                     |
     |               |                                           |
     | TCP           |            Port                           |
     | SCTP          |            syn                            |
     | DCCP          |            ack                            |
     |               |            fin                            |
     |               |            rst                            |
     |               |          ? psh                            |
     |               |          ? urg                            |
     |               |          ? window                         |
     |               |            sockstress                     |
     | UDP           |                                           |
     |               |            flood abuse                    |
     |               |            fragment abuse                 |
     |               |            Port                           |
     | HTTP layer    |                                           |
     |               |          | hash collision                 |
     |               |          | http - get flood               |
     |               |          | http - post flood              |
     |               |          | http - random/invalid url      |
     |               |          | http - slowloris               |
     |               |          | http - slow read               |
     |               |          | http - r-u-dead-yet (rudy)     |
     |               |          | http - malformed request       |
     |               |          | http - xss                     |

xxx, et al.            Expires December 3, 2015                [Page 9]
Internet-Draft              I2NSF Framework                   June 2015

     |               |          | https - ssl session exhaustion |
     +---------------+----------+--------------------------------+
     | IETF PCP      | Configurable                              |
     |               | Ports                                     |
     |               |                                           |
     +---------------+-------------------------------------------+
     | IETF TRAM     | profile                                   |
     |               |                                           |
     |               |                                           |
     |---------------+-------------------------------------------+

     +-----------------------------------------------------------+
     |      Object (context) matching Capability Index           |
     +---------------+-------------------------------------------+
     | Session       |   Session state,                          |
     |               |   bidirectional state                     |
     |               |                                           |
     +---------------+-------------------------------------------+
     | Time          |   time span                               |
     |               |   days, minutes, seconds,                 |
     |               |   Events                                  |
     +---------------+-------------------------------------------+
     | Events        |   Event URL, variables                    |
     +---------------+-------------------------------------------+

     +-----------------------------------------------------------+
     |      Action Capability Index                              |
     +---------------+-------------------------------------------+
     | Ingress port  |   SFC header termination ,                |
     +---------------+-------------------------------------------+
     |               |   Pass                                    |
     | Egress        |   Deny                                    |
     |               |   Mirror                                  |
     |               |   Functional call                         |
     |               |   Encap various header                    |
      +---------------+-------------------------------------------+

     +-----------------------------------------------------------+
     |      Functional profile Index                             |
     +---------------+-------------------------------------------+
     | Profile types |   Name, type, or                          |
     | Signature     |   Flexible Profile/signature URL          |
     |               | Command for Controller to enable/disable  |
     |               |                                           |
      +---------------+-------------------------------------------+

xxx, et al.            Expires December 3, 2015               [Page 10]
Internet-Draft              I2NSF Framework                   June 2015

5. Security Policies Provisioning to NSFs

             +------------------------------------------+
             |             App Gateway                  |
             |       (e.g. Video conference Ctrl        |
             | Admin, OSS/BSS, or Service Orchestration |
             +---------------------+--------------------+
                         I2NSF     |Service Layer Security Policy
                                   |
                    +--------------+----------------+
                    |        Security Controller    |
                    +--------------+----------------+
                         I2NSF     |Capability Layer Security Policy
                                   |
                           +------------------+
                           |     Adapter      |
                           +------------------+
                           | virtual/physical |
                           |       NSFs       |
                           +------------------+
               Figure 3: Multiple Layers of I2NSF interfaces

5.1. Capability Layer Provisioning and Monitoring

   The Capability Layer is to express the explicit provisioning rules
   to individual NSFs and methods to monitor the execution status of
   those functions.

   This requires the definition of an information model, along with one
   or more data models, to express the provisioning rules, which are
   derived from the client facing security policies.

   This layer will leverage the existing protocols and data models
   defined by I2RS, Netconf, and NETMOD.

   [ACL-MODEL] is for expressing the Access Control List supported by
   most routers/switches that forward packets based on packets' L2, L3,
   or sometimes L4 headers. The actions for Access Control List include
   Pass, Drop, or Redirect.

xxx, et al.            Expires December 3, 2015               [Page 11]
Internet-Draft              I2NSF Framework                   June 2015

   The functional profiles (or signatures) for NSFs are not present in
   [ACL-MODEL] because the functional profiles are unique to specific
   NSFs. Most vendors' IPS/IDS, and HoneyPot have their proprietary
   functions/profiles. One of the goals of I2NSF is to have common
   envelop format for exchanging or sharing profiles among different
   organizations to achieve more effective protection against threats.

   The "subject" of the policies not only includes the matching
   criteria specified by [ACL-MODEL] but also the L4-L7 fields
   depending on the NSF selected.

   The I2NSF Capability Layer has to specify the "Object" (i.e. the
   states/contexts surrounding the packets).

   The I2NSF "actions" are similar to the actions specified by [ACL-
   MODEL].

   This layer also includes the policy monitoring of the individual
   NSFs and fault management of the policy execution. In NFV
   environment, policy consistency among multiple security function
   instances is very critical because security policies are no longer
   maintained by one central security devices, but instead are enforced
   by multiple security functions instantiated at various locations.

5.2. Service Layer Security Policy

   This layer is for customers or Application Gateway to express &
   monitor the needed security policies for their specific flows.

   Customers may not have security skills. As such, they are not able
   to express requirements or security policies that are precise
   enough. Usually these customers are expressing expectations (that
   can be viewed as loose security requirements). Customers may also
   express guidelines such as which critical communications are to be
   preserved during critical events, which hosts are to service even
   during severe security attacks, etc.

   Here are some examples of Service Oriented Security Policies:

          o Pass FW/IPS for Subscriber "xxx" with Port "y"
          o enable basic parental control
          o enable "school protection control"
          o allow Internet traffic from 8:30 to 20:00 [time = 8:30-
            20:00]

xxx, et al.            Expires December 3, 2015               [Page 12]
Internet-Draft              I2NSF Framework                   June 2015

          o scan email for malware detection [check type = malware]
            protect traffic to corporate network with integrity and
            confidentiality [protection type = integrity AND
            confidentiality]
          o remove tracking data from Facebook [website =
            *.facebook.com]
          o my son is allowed to access facebook from 18:30 to 20:00

   One Service Layer Security Policy may need multiple security
   functions at various locations to achieve the enforcement. Service
   layer Security Policy may need to be updated by users or Application
   Gateway when user's service requirements have been changed.

   I2NSF will not standardize the Service Layer security policies.
   [I2NSF-Demo] describes an implementation of translating a set of
   Service Layer policies to the Capability Layer instructions to NSFs.

6. Capability Negotiation

     When a NSF can't perform the desired provisioning due to resource
     constraint, it has to inform the controller.

     The protocol needed for this security function/capability
     negotiation may be somewhat correlated to the dynamic service
     parameter negotiation procedure [RFC7297]. The CPP template
     documented in RFC7297, even though currently covering only
     Connectivity (but includes security clauses such as isolation
     requirements, non-via nodes, etc.), could be extended as a basis
     for the negotiation procedure. Likewise, the companion CPNP could
     be a candidate to proceed with the negotiation procedure.

     The "security as a service" would be a typical example of the kind
     of (CPP-based) negotiation procedures that could take place
     between a corporate customer and a service provider. However, more
     security specific parameters have to be considered by this
     proposed work.

xxx, et al.            Expires December 3, 2015               [Page 13]
Internet-Draft              I2NSF Framework                   June 2015

7. Types of I2NSF clients

   It is envisioned that I2NSF clients include:

   - Application Gateway:

        -                 For example, Video Conference Mgr/Controller needs to
          dynamically inform some FW/IPS/IDS security functions on
          special policies based specific fields in the packets for the
          specific encrypted flows for a certain time span. Otherwise,
          some flows can't go through the FW/IPS/IDS because the
          payload is encrypted.

   - Security Administrators

          - Enterprise
          - Operator Management System dynamically update, monitor and
            verify the security policies to security functions
          - Third party system
          - management system

   - Security functions send requests for more sophisticated functions
     upon detecting something suspicious

8. Manageability Considerations

     Management of NSFs usually include configuration of devices,
     signaling and policy provisioning. I2NSF will only focus on the
     policy provisioning part.

9. Security Considerations

     Having a secure access to control and monitor NSFs is crucial for
     hosted security service. Therefore, proper secure communication
     channels have to be carefully specified for carrying the
     controlling and monitoring information between the NSFs and their
     management entity (or entities).

xxx, et al.            Expires December 3, 2015               [Page 14]
Internet-Draft              I2NSF Framework                   June 2015

10. IANA Considerations

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

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.

   [RFC7297] Boucadair, M., "IP Connectivity Provisioning Profile",
             RFC7297, April 2014.

 11.2. Informative References

   [Packet-Based-NSF] E. Lopez, "Packet-Based Paradigm For Interfaces
             to NSFs", <draft-lopez-i2nsf-packet-00>, in-progress,
             March 2015.

   [I2NSF-ACCESS] A. Pastor, et al, "Access Use Cases for an Open OAM
             Interface to Virtualized Security Services", <draft-
             pastor-i2nsf-access-usecases-00>, Oct 2014.

   [I2NSF-DC] M. Zarny, et al, "I2NSF Data Center Use Cases", <draft-
             zarny-i2nsf-data-center-use-cases-00>, Oct 2014.

   [I2NSF-MOBILE] M. Qi, et al, "Integrated Security with Access
             Network Use Case", <draft-qi-i2nsf-access-network-usecase-
             00>, Oct 2014

   [I2NSF-Problem] L. Dunbar, et al "Interface to Network Security
             Functions Problem Statement", <draft-dunbar-i2nsf-problem-
             statement-01>, Jan 2015

   [ACL-MODEL] D. Bogdanovic, et al, "Network Access Control List (ACL)
             YANG Data Model", <draft-ietf-net-acl-model-00>, Nov 2014.

xxx, et al.            Expires December 3, 2015               [Page 15]
Internet-Draft              I2NSF Framework                   June 2015

   [gs_NFV] ETSI NFV Group Specification, Network Functions
             Virtualizsation (NFV) Use Cases. ETSI GS NFV 001v1.1.1,
             2013.

   [NW-2011] J. Burke, "The Pros and Cons of a Cloud-Based Firewall",
             Network World, 11 November 2011

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

   [I2NSF-Demo] Y. Xie, et al, "Interface to Network Security Functions
             Demo Outline Design", <draft-xie-i2nsf-demo-outline-
             design-00>, April 2015.

12. Acknowledgments

   Acknowledgements to xxx for his review and contributions.

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

xxx, et al.            Expires December 3, 2015               [Page 16]
Internet-Draft              I2NSF Framework                   June 2015

Authors' Addresses

   Diego Lopez
   Telefonica
   Email: diego.r.lopez@telefonica.com

   XiaoJun Zhuang
   China Mobile
   Email: zhuangxiaojun@chinamobile.com

   Linda Dunbar
   Huawei
   Email: Linda.Dunbar@huawei.com

   Joe Parrott
   BT
   Email: joe.parrott@bt.com

   Ramki Krishnan
   Brocade
   Email: ramk@brocade.com

   Seetharama Rao Durbha
   CableLabs
   Email: S.Durbha@cablelabs.com

xxx, et al.            Expires December 3, 2015               [Page 17]