Internet DRAFT - draft-dunbar-l4-l7-sc-problem-statement
draft-dunbar-l4-l7-sc-problem-statement
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]
