[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Nework working group                                      L. Dunbar
Internet Draft                                          D. Eastlake
Intended status: Informational                               Huawei
Expires: January 2014


                                                      July 11, 2013

               Layer 4-7 Service Chain problem statement
             draft-dunbar-l4-l7-sc-problem-statement-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. Code Components extracted from this
   document must include Simplified BSD License text as described in




Dunbar                Expires January 11, 2014                [Page 1]


Internet-Draft  Layer 4-7 Service Chain Problem Statement


   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 taxonomy of Layer 4-7 Services and gives
   two examples of Layer 4-7 service chain, one from a traffic
   steering perspective and another one from a Layer 7 perspective.
   The intent is to emphasize their unique issues and challenges.

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. Taxonomy of Layer 4-7 Services ............................... 3
      3.1. Layer 4-7 Traffic Steering (or Forwarding)............... 4
      3.2. Layer 4-7 Service Function .............................. 4
      3.3. Service Module connection to Service Chain Steering
      Points ....................................................... 5
   4. Challenges of Service Chain from Traffic Steering Perspective .7
      4.1. Challenges of Layer 4-7 traffic Steering................. 9
      4.2. Challenge of traffic steering along service chain ....... 9
      4.3. Challenges of Flow Marking for Service Chain ........... 10
      4.4. Ways to Minimize Impact to Existing Network............. 10
   5. Challenge of Service Chain from the Layer 7 Perspective ..... 13
   6. Conclusion and Recommendation ............................... 13
   7. Manageability Considerations ................................ 14
   8. Security Considerations ..................................... 14
   9. IANA Considerations ......................................... 14
   10. Acknowledgments ............................................ 14
   11. References ................................................. 14
   Authors' Addresses ............................................. 15
   Intellectual Property Statement ................................ 15
   Disclaimer of Liability ........................................ 15


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


Internet-Draft  Layer 4-7 Service Chain Problem Statement





1. Introduction

   This draft analyzes the taxonomy of Layer 4-7 Services and gives
   two examples of Layer 4-7 service chain, one from a traffic
   steering perspective and another one from a Layer 7 perspective.
   The intent is to emphasize their unique issues and challenges.

   Layer 4-7 services and service chains have been discussed in many
   forums, such as ETSI NFV, ONF, and IETF I2RS Interim meetings.
   However, people from different background frequently have
   different interpretations of Layer 4-7 services and service
   chains. For example, network vendors tend to view "Layer 4-7
   Service Chains" as forwarding (or steering) traffic to a sequence
   of service modules based on Layer 4-7 fields, whereas Layer 4-7
   vendors may view "service chains" as reassembling whole HTTP
   messages (which could be in multiple data frames) and applying
   the needed functions (e.g. Content Optimization or App Security)
   based on some logics formulated from the message content. This
   draft starts with analyzing the taxonomy Layer 4-7 services and
   service chains.



2. Terminology

   DPI       Deep Packet Inspection
   FW        Firewall


3. Taxonomy of Layer 4-7 Services

   Layer 4-7 Services can be broadly broken into two categories:

   1) Layer 4-7 Traffic Steering: a functional module in a device
   that forwards data packets received from one port to another port
   based on Layer 4 to Layer 7 fields in the data packets.

   2) Layer 4-7 Service Function:  a functional module that performs
   Layer 4 to 7 functions, such as Firewall, DPI, TCP accelerator,
   NAT, etc. When Layer 4-7 service function is instantiated on a
   standalone physical or virtual device, it is called Layer 4-7
   Service module throughout this draft. Layer 4-7 functions can



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


Internet-Draft  Layer 4-7 Service Chain Problem Statement


   also be embedded in another device, such as router/switch or
   other devices.



3.1. Layer 4-7 Traffic Steering (or Forwarding)

   Layer 4-7 Traffic Steering (or forwarding) basically forwards
   data packets received from one port to another port based on some
   higher layer fields in the data packets.

   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, MPLS label, or VLAN
              ID.

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

   Since routers/switches all forward data packets based Layer 2 or
   3 header, for ease of description "Service Chain Steering Point
   (or Node)" is used throughout this draft to refer to the entities
   that steer traffic to a sequence of service modules.

   Note: the Layer 4-7 traffic steering could also steer packets to
   a service module that applies non-Layer4-7 functions.

3.2. Layer 4-7 Service Function

   A Layer 4-7 Service Function, or service module if it is in a
   standalone device or virtual device, performs a Layer 4 to 7
   function based on packets received. One service module can
   contain multiple service functions. Examples are: Firewall, DPI,


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


Internet-Draft  Layer 4-7 Service Chain Problem Statement


   TCP accelerator, NAT, etc. Service Module could be Proxy based or
   Packet Based.  Note the criteria to apply Layer 4-7 functions can
   be based on Layer 2 or 3 fields of the data packets received. On
   traditional routers/switches, there are Layer 2 or 3 service
   functions, such as frame fragmentation and reassembly. Layer 2 or
   3 service functions are out of the scope of this draft.

   A Layer 7 service function can be very different from a Layer 4
   service function. It is necessary to differentiate them. To be
   specific, there are

     - Layer 4 service function
     - Layer 7 service function
     - Layer 4 service function with some Layer 7 intelligence.


   The service modules can be further distinguished by

     - 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 modules
       maintain original packets, i.e. they don't make changes to
       packets traversed through except possibly to metadata such as
       VLAN tags.


   An entity (physical or virtual device) that can forward packets
   after one service module to another service module is considered
   as having two functions: a Service Function integrated with a
   Traffic Steering function.



3.3. Service Module connection to Service Chain Steering Points

   Service modules can be connected to Service Chain steering points
   (such as routers/switches) in various ways:

     - A service module can be embedded in a traffic steering node
       (i.e. embedded in a router or a switch).




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


Internet-Draft  Layer 4-7 Service Chain Problem Statement


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



     - A service module can be one hop away from a traffic steering
       node

       The one hop between the Service Chain Steering node and the
       service module can be a physical link (e.g. Ethernet link) or
       one virtual tunnel (e.g. VxLAN).

       If the one hop is a physical Ethernet link, there would be a
       Link Header, i.e. an outer MAC header, added to the data
       packets that meet the steering criteria, with MAC Source
       Address being the Service Chain Steering Node and MAC
       Destination Address being the Service module for packets from
       the Service Chain Steering node to the service module.

       For the reverse direction over this link, i.e. after the
       service module process the packets, the MAC Source Address is
       the Service Module and the MAC Destination Address is the
       Service Chain Steering node.

       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 Steering node and Service Module. This scenario
       is considered the same as a service module being embedded in
       the Service Chain Steering node.

       The one hop between the Service Steering node and a service
       module can also be a tunnel, like a VxLAN tunnel. Under this
       case, the tunnel header has to be added to the data packets
       that meet the steering criteria for those packets to be sent
       to the service modules. After the service module processes
       the data packets, the Tunnel header has to be added to the
       packets for them to be sent back to the Service Chain
       Steering node.





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


Internet-Draft  Layer 4-7 Service Chain Problem Statement


     - A service module can be multiple hops away from a Service
       Chain Steering node

4. Challenges of Service Chain from Traffic Steering Perspective

   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 flow. A flow is loosely used in this document to
   refer to a selective of packets that meet certain criteria. Some
   users might not care at which points in the network the selected
   flow is steered to those service modules as long as the sequence
   of the service modules is correct.

   From the traffic steering perspective, a Service Chain guarantees
   that specific data flows go through a specific sequence of
   service modules at designated points along the flow paths in the
   network, as shown in the figure below. The service modules
   perform some functions on the data packets in the flows, such as
   Firewall, NAT, QoS insertion, etc.





























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


Internet-Draft  Layer 4-7 Service Chain Problem Statement




                                             .       @
                                              .       @
    +--------------+                          V       V
    |            ..+<..........          +----+-------+-------+
    | Service 1  . |           .         |    .       @       |
    |            ..+.......     .........+....    @@@@        |
    +--------------+       .             |       @            |
                            ............>+...    @            |
                                         |  .    @            |
                            @@@@@@@@@@@@@+@@+@@@@   Traffic   |
    +--------------+       @             |  .       Steering  |
    |            @@+<@@@@@@    @@@@@@@@@>+@@+@@@    Point     |
    | Service 2  @ |          @          |  .   @             |
    |            @@+@@@@@@@@@@           +--+---+-------------+
    +--------------+                        .   @
                                            .   @
                                            .   @
    +----------------+                      V   V
    |              ..+<...........       +--+---+-------------+
    |              . |            .      |  .   @             |
    |            @@+@+<@@@@@@@     ......+..    @             |
    | Service 3  @ . |        @          |      @             |
    |            @ ..+......   @@@@@@@@@@+@@@@@@              |
    |            @   |      .            |          Traffic   |
    |            @@@@+@@@    ...........>+...       Steering  |
    +----------------+   @               |  .       Point     |
                          @@@@@@@@@@@@@@>+@@+@@@              |
                                         |  .   @             |
                             ............+...    @@@@@        |
    +--------------+        .            |            @       |
    |            ..+<.......     .......>+....        @       |
    | Service 4  . |            .        |    .       @       |
    |            ..+............         +----+-------+-------+
    +--------------+                          .       @
                                              .       @
                                              V       V

   Figure 1: Simple Service Chain from Traffic Steering Point of
   View










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


Internet-Draft  Layer 4-7 Service Chain Problem Statement




4.1. Challenges of Layer 4-7 traffic Steering

   Very often the criteria for steering flows to service modules 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.



4.2. Challenge of traffic steering along service chain

   From traffic steering point of view, one service chain consists
   of:

   - Identifier
   - {Steering point List}
   - Steering Point #1, {list of Service Modules}
   - Steering Point #2, {list of Service Modules}
   - ?

   Two service chains with the same sequence of service modules but
   different steering points should be considered as two different
   service chains from traffic steering point of view.

   Some service modules change values in 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 modules.

   Even though it is out of the scope of this draft, it is assumed
   that the Service Chain Orchestration System can create service
   chains in a way that allows each service chain to be shared by
   many flows while maintaining optimized utilization of network
   resources.


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


Internet-Draft  Layer 4-7 Service Chain Problem Statement




4.3. Challenges of Flow Marking for Service Chain

   The policy for associating flows with their service chains can be
   complicated and could be dynamic. Sometimes it might not be
   possible to predict what traffic is traversed through and which
   paths traversed by.

   The entity that is responsible for associating flows with their
   specific service Chains is called Service Chain Marking
   Functional Module in this document. The Service Chain Marking
   Functional Module can encounter flows that don't match with any
   policies. External entity (or controller) might be needed for a
   Service Chain Marking Functional Module to make appropriate
   decision.

   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.


4.4. Ways to Minimize Impact to Existing Network

   To minimize impact to deployed network elements
   (switches/routers), traffic flows can be classified or marked
   based on service chain requirement at network ingress edges, as
   shown in the diagram below.














Dunbar, et al           Expires Sept11, 2014            [Page 10]


Internet-Draft  Layer 4-7 Service Chain Problem Statement


                                      \    \   \   /   /   /    /

                                      \    \   \  |  /   /    /
                                       \    \  |  |  |  /    /
      +------------+                    \   |  |  |  |  |   /
      | Controller |------\              +--+--+--+--+--+--+
      +------------+       \             |                 |
                            \----------->|    SC Marking   |
                                         |    .       @    |
                                         +----+-------+----+
                                              .       @
                                              .       @
    +--------------+                          V       V
    |            ..+<..........          +----+-------+-------+
    | Service 1  . |           .         |    .       @       |
    |            ..+.......     .........+....    @@@@        |
    +--------------+       .             |       @            |
                            ............>+...    @            |
                                         |  .    @  Service   |
                            @@@@@@@@@@@@@+@@+@@@@   Chain     |
    +--------------+       @             |  .       Steering  |
    |            @@+<@@@@@@    @@@@@@@@@>+@@+@@@    Point#1   |
    | Service 2  @ |          @          |  .   @             |
    |            @@+@@@@@@@@@@           +--+---+-------------+
    +--------------+                        .   @
                                            .   @
                                            .   @
    +----------------+                      V   V
    |              ..+<...........       +--+---+-------------+
    |              . |            .      |  .   @             |
    |            @@+@+<@@@@@@@     ......+..    @             |
    | Service 3  @ . |        @          |      @             |
    |            @ ..+......   @@@@@@@@@@+@@@@@@    Service   |
    |            @   |      .            |          Chain     |
    |            @@@@+@@@    ...........>+...       Steering  |
    +----------------+   @               |  .       Point #2  |
                          @@@@@@@@@@@@@@>+@@+@@@              |
                                         |  .   @             |
                             ............+...    @@@@@        |
    +--------------+        .            |            @       |
    |            ..+<.......     .......>+....        @       |
    | Service 4  . |            .        |    .       @       |
    |            ..+............         +----+-------+-------+
    +--------------+                          .       @
                                              .       @
                                              V       V

              Figure 2: Service Chain Marking At Ingress



Dunbar, et al           Expires Sept11, 2014            [Page 11]


Internet-Draft  Layer 4-7 Service Chain Problem Statement




   The purpose of a Service Chain Marking Functional Module is to
   add 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 modules specified by the flow's service chain. The
   network elements that have the Service Chain Marking Function are
   most likely network ingress edge nodes, such as Broadband Network
   Gateways, Cell Site Gateways, etc.

   For example, the Service Chain Marking Functional Module can mark
   packets in a flow with a VLAN or MPLS label, based on the flow's
   service chain requirement.

   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 Marking
   Functional Module 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.

   To minimize changes to deployed network elements, a small number
   of nodes in network can be designated to have the responsibility
   of steering traffic to the designated service modules. For ease
   of description, those nodes are called Service Chain Steering
   Points in this draft.

   Overlay tunnels, such as VxLAN, can be used to force flows to
   traverse their designated Service Chain Steering Points. By using
   overlay tunnels, the existing network elements don't need to
   change any forwarding behavior.

   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 Steering Point
   #1 and "Service-3" at Steering Point #2, the forwarding rule for
   VLAN ID=10 can be pre-configured at Steering Point #1 and
   Steering Point #2.










Dunbar, et al           Expires Sept11, 2014            [Page 12]


Internet-Draft  Layer 4-7 Service Chain Problem Statement




5. 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 modules to be
   chained can depend on the HTTP message request and reply. The
   service chain steering point may have to examine the whole HTTP
   message to determine the specific sequence of service modules for
   packets to traverse through. The HTTP message might have to be
   extracted from multiple data packets. Sometimes, the logic to
   steer traffic to chain of service modules might depend on the
   data retrieved from a database based on messages constructed from
   packets.


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

   Figure 3: Layer 7 Service Chain Complexity



6. Conclusion and Recommendation

   Service Chain touches upon Layer 2 to Layer 7. Challenges for
   Layer 4-7 service chain can be different from Layer 2-3.

   This document provides common baseline for Layer 4-7 services
   and service chain and addresses their unique challenges.







Dunbar, et al           Expires Sept11, 2014            [Page 13]


Internet-Draft  Layer 4-7 Service Chain Problem Statement


7. Manageability Considerations

   TBD.

8. Security Considerations

   TBD.

9. IANA Considerations

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

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

11. References

   [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>, July, 2013



















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


Internet-Draft  Layer 4-7 Service Chain Problem Statement


Authors' Addresses

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


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


Internet-Draft  Layer 4-7 Service Chain Problem Statement


   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 Sept11, 2014            [Page 16]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/