Network working group                                     L. Dunbar
Internet Draft                                               Huawei
Intended status: Informational                   I. Smith; S. Majee
Expires: January 2014                                  F5 Networks
                                                             N. So
                                                Tata Communications
                                                   Donald Eastlake
                                                            Huawei


                                                   October 16, 2013

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


Status of this Memo

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

   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



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.

Dunbar                 Expires April 16, 2014             [Page 1]


Internet-Draft  Architecture for Chaining Legacy L4-L7 SF






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 and describe gaps that have not been
   addressed by other SFC drafts.

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 0.

   The term "traffic steering" and "traffic forwarding" are used
   interchangeably in this draft.

Table of Contents


   1. Introduction.................................................3
   2. Terminology..................................................3
   3. Layer 4-7 Service Functions and Chaining.................... 4
      3.1. Layer 4-7 Service Functions ............................4
      3.2. Service Functions for Wireless network  ................4
      3.3. Proxy Node for Layer 4-7 Service Functions   ...........5
   4. Architecture for Chaining Legacy Layer 4-7 Service Functions.7
      4.1. L4-L7 nodes connection to Service Chain Proxy Nodes ....7
      4.2. Traffic Steering at Proxy Nodes.........................7
   5. Challenges of Chaining L4-L7 Service Function ...............9
      5.1. Challenge of Multiple Instances of a Service Function ..9
      5.2. Challenges of Layer 4-7 traffic Steering ...............10


Dunbar, et al           Expires Sept16, 2014             [Page 2]


Internet-Draft  Architecture for Chaining Legacy L4-L7 SF


      5.3. Challenges of Service Chain Classification .............11
   6. Challenge of Service Chain from the Layer 7 Perspective .....12
   7. Conclusion and Recommendation .............................  13
   8. Manageability Considerations ..............................  13
   9. Security Considerations ...................................  13
   10. IANA Considerations ......................................  13
   11. Acknowledgments..........................................   14
   12. References...............................................   14
   Authors' Addresses...........................................   15
   Intellectual Property Statement ................................15
   Disclaimer of Liability ......................................  16



1. Introduction

   This draft focuses on the issues associated with chaining common
   Layer 4-7 Service functions that are not aware of new service
   encapsulation layers. Some examples of service function chaining
   in the mobile network environment are studied in this draft.  The
   intent is to demonstrate gaps that haven't been addressed by
   other Service Function Chaining (SFC) drafts.

   There have been many drafts submitted on the topic of SFC.
   However, a number of issues associated with chaining existing
   Layer 4-7 service functions that don't support Service
   Encapsulation header have not been described well.



2. Terminology

   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



Dunbar, et al           Expires Sept16, 2014             [Page 3]


Internet-Draft  Architecture for Chaining Legacy L4-L7 SF


   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. Layer 4-7 Service Functions and Chaining

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.

     - 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.

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


3.2. Service Functions for Wireless network

   [SFC-MobileNetwork] and [SFC-use-cases] have provided examples of
   service chain in mobile network. In particular, the P-GW/PCEF
   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:

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


Dunbar, et al           Expires Sept16, 2014             [Page 4]


Internet-Draft  Architecture for Chaining Legacy L4-L7 SF


     - 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.
     - 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 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.




Dunbar, et al           Expires Sept16, 2014             [Page 5]


Internet-Draft  Architecture for Chaining Legacy L4-L7 SF


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



                          |1  -----   |n        |21   ---- |2m
                      +---+---+   +---+---+   +-+---+   +--+-----+
                      | Ad    |   |Content|   |Video|   |Security|
                      |Insert |   | Opt   |   | Opt |   | App    |
                      +---+---+   +---+---+   +--+--+   +--+--+--+
                          :           :           :         :  :
                          :           :           :         :  :
                           \         /              \      /
       +--------------+     +--------+              +---------+
  -- > | Chain        | --> | Proxy  |--------->    | Proxy   | ------>
       |classification|     |Node-1  |              | Node-i  |
       +--------------+     +----+---+              +----+--+-+
                                 |--                     |  |
                                 V                       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 the service chain "proxy nodes", the Proxy
   nodes need 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.









Dunbar, et al           Expires Sept16, 2014             [Page 6]


Internet-Draft  Architecture for Chaining Legacy L4-L7 SF


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.

     - 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.

     - 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.

     - 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


Dunbar, et al           Expires Sept16, 2014             [Page 7]


Internet-Draft  Architecture for Chaining Legacy L4-L7 SF


   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 can be dynamically updated by network controller to the
   proxy nodes.

   There are multiple types of traffic steering:

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

            ?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.

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

            ?QoS header based forwarding.

       - 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.

       - 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).





Dunbar, et al           Expires Sept16, 2014             [Page 8]


Internet-Draft  Architecture for Chaining Legacy L4-L7 SF







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.
   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.











Dunbar, et al           Expires Sept16, 2014             [Page 9]


Internet-Draft  Architecture for Chaining Legacy L4-L7 SF


                          |
                      +---+------+               +---+---+   +--+-----+
                      |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 Sept16, 2014            [Page 10]


Internet-Draft  Architecture for Chaining Legacy L4-L7 SF


                          |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 Sept16, 2014            [Page 11]


Internet-Draft  Architecture for Chaining Legacy L4-L7 SF


   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:

   - Criteria for Flow X to the Service Chain "A" are TCP port
   - Criteria for Flow Y to the Service Chain "A" are Destination
     Address
   - 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 Sept16, 2014            [Page 12]


Internet-Draft  Architecture for Chaining Legacy L4-L7 SF


                     +----------+
    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 Sept16, 2014            [Page 13]


Internet-Draft  Architecture for Chaining Legacy L4-L7 SF


11. Acknowledgments

   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.

12. 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, "Network Service Chaining Problem
            statement", <draft-quinn-nsc-problem-statement-03>,
            Aug, 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












Dunbar, et al           Expires Sept16, 2014            [Page 14]


Internet-Draft  Architecture for Chaining Legacy L4-L7 SF



Authors' Addresses

   Linda Dunbar
   Huawei Technologies
   1700 Alma Drive, Suite 500
   Plano, TX 75075, USA
   Phone: (469) 277 5840
   Email: ldunbar@huawei.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



Intellectual Property Statement

   The IETF Trust takes no position regarding the validity or scope
   of any Intellectual Property Rights or other rights that might be
   claimed to pertain to the implementation or use of the technology
   described in any IETF Document or the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights.

   Copies of Intellectual Property disclosures made to the IETF
   Secretariat and any assurances of licenses to be made available,
   or the result of an attempt made to obtain a general license or
   permission for the use of such proprietary rights by implementers



Dunbar, et al           Expires Sept16, 2014            [Page 15]


Internet-Draft  Architecture for Chaining Legacy L4-L7 SF


   or users of this specification can be obtained from the IETF on-
   line IPR repository at http://www.ietf.org/ipr

   The IETF invites any interested party to bring to its attention
   any copyrights, patents or patent applications, or other
   proprietary rights that may cover technology that may be required
   to implement any standard or specification contained in an IETF
   Document. Please address the information to the IETF at ietf-
   ipr@ietf.org.

Disclaimer of Liability

   All IETF Documents and the information contained therein are
   provided on an "AS IS" basis and THE CONTRIBUTOR, THE
   ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE
   INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.























Dunbar, et al           Expires Sept16, 2014            [Page 16]