Internet DRAFT - draft-rijsman-sfc-metadata-considerations
draft-rijsman-sfc-metadata-considerations
Service Function Chaining (SFC) B. Rijsman
Internet Draft J. Moisand
Intended status: Informational Juniper Networks
Expires: August 2014 February 12, 2014
Metadata Considerations
draft-rijsman-sfc-metadata-considerations-00.txt
Status of this Memo
This Internet-Draft is submitted 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
This Internet-Draft will expire on August 12, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Rijsman Expires August 12, 2014 [Page 1]
Internet-Draft Metadata Considerations February 2014
Abstract
This draft discusses the topic of metadata in the context of Service
Function Chaining. It aims to define the problem space for metadata
signaling, identify the key challenges, and guide the exploration
and comparison of possible solutions.
Table of Contents
1. Introduction...................................................3
2. Metadata use cases.............................................3
2.1. What is metadata?.........................................3
2.2. Contextual information which is not locally available.....4
2.3. Avoiding repeated execution of expensive operations.......5
2.4. Fine-grained policies.....................................6
3. Metadata signaling approaches..................................8
3.1. In-band marking...........................................8
3.2. Metadata in application layer headers.....................9
3.3. Congruent out-of-band metadata signaling.................10
3.4. Non-congruent out-of-band metadata signaling.............11
3.5. Hybrid in-band marking and out-of-band signaling.........12
4. Metadata challenges...........................................13
4.1. Support for metadata-unaware Service Functions...........13
4.2. Preserving metadata through metadata-unaware Service
Functions.....................................................14
4.3. Metadata encoding........................................17
4.4. Scalability and performance of the control plane.........18
4.5. Synchronization between the control plane and the data plane
..............................................................18
4.6. Distributing metadata only to interested Service Functions19
4.7. Associating data plane flows with control plane signaling20
4.8. Layering considerations..................................20
4.9. Load balancing and symmetry..............................23
4.10. High availability and geographic dispersion.............24
4.11. Multiple sources of metadata............................24
4.12. Extensibility...........................................25
5. Conclusion....................................................25
6. Security Considerations.......................................27
7. IANA Considerations...........................................27
8. References....................................................27
8.1. Normative References.....................................27
8.2. Informative References...................................27
9. Acknowledgments...............................................29
Rijsman, et al. Expires August 12, 2014 [Page 2]
Internet-Draft Metadata Considerations February 2014
1. Introduction
This draft discusses the topic of metadata in the context of Service
Function Chaining.
As described in [draft-quinn-sfc-arch] a Service Function Chain (or
Service Chain for short) is a sequence of Service Functions such as
Network Address Translation (NAT), Firewalls, Deep Packet Inspection
(DPI), Intrusion Detection Systems (IDS), content caches, etc.
Service Functions process the traffic flows which traverse the
Service Function Chain. In additional to the data which is in the
processed traffic flow itself, the Service Functions may also
benefit from additional contextual information about the traffic
flows. This additional contextual information is referred to as
metadata. One example of metadata is an Accounting-ID which is used
for accounting and billing purposes.
This draft aims to define the problem space for metadata signaling,
identify candidate approaches, describe the key challenges, and
guide the exploration and comparison of possible solutions.
Section 2 defines what metadata is and what it can be used for, i.e.
use cases for metadata.
Section 3 lists five different approaches for signaling metadata:
in-band signaling (attaching metadata to each packet in a traffic
flow), signaling metadata in application layer headers, congruent
out-of-band metadata signaling, non-congruent out-of-band metadata
signaling, and a hybrid approach combining in-band signaling with
out-of-band signaling.
Section 4 discusses various challenges with metadata and describes
the pros and cons of each of the five approaches in terms of dealing
with these challenges.
Section 5 contains a summary and conclusion.
2. Metadata use cases
2.1. What is metadata?
Metadata is "data about data".
In the context of Service Function Chaining, metadata provides
contextual information about the data packets which traverse a
Service Function Chain.
Rijsman, et al. Expires August 12, 2014 [Page 3]
Internet-Draft Metadata Considerations February 2014
The following sections provide concrete examples of what metadata
can be used for.
2.2. Contextual information which is not locally available
Metadata can be used to transport contextual information which is
available at one location in the network to another location in the
network where that information is not readily available.
Edge routers often have detailed information about each traffic flow
such as the subscriber identity (Subscriber-ID) and the associated
policies (i.e. sets of rules which need to be applied to the traffic
flow).
This information is available at the network edge as a result of the
customer-facing interface on which the traffic arrives, or as a
result of information in encapsulations or protocols which are
stripped off at the edge of the network, or as a result of
interactions with policy servers such as Authentication,
Authorization, and Accounting (AAA) servers.
Deeper in the network this detailed information is either not
available or difficult to obtain.
We illustrate this using two concrete examples:
o In Long Term Evolution (LTE) mobile networks, the Packet Data
Network Gateway (PGW) sits at the edge of the IP network. The
PGW decapsulates packets from the General Packet Radio Service
Tunneling Protocol (GTP). The PGW uses the Diameter protocol
[RFC6733] to interact with the Policy and Charging Rules Function
(PCRF) server. As a result, the PGW knows the subscriber
identity and policy for each traffic flow. This information is
not easily available deeper in the network.
o In fixed broadband networks, the Broadband Network Gateway (BNG)
sits at the edge of the IP network. The BNG decapsulates packets
from a variety of encapsulations such as Point-to-Point over
Ethernet (PPPoE). The BNG interacts with an Authentication,
Authorization, and Accounting (AAA) server using the Remote Dial
In User Service (RADIUS) protocol. As a result, the BNG know the
subscriber identity and policy for each traffic flow. This
information is not easily available deeper in the network.
These edge routers (such as PGWs or BNGs) may be used as the
starting point for a Service Function Chain.
Rijsman, et al. Expires August 12, 2014 [Page 4]
Internet-Draft Metadata Considerations February 2014
Metadata can be used to signal information from the place where it
is readily available (e.g. the PGW or the BNG at the start of the
Service Function Chain) to places deeper in the network where it is
not readily available (e.g. the Service Functions in the Service
Function Chain).
Examples of such metadata include:
o A Subscriber-ID, or more accurately, an Accounting-ID which maps
traffic flows to a unique identifier used for accounting and
billing purposes.
o A Service-Profile-ID and/or Service-Profile-Parameters which
identify the service which the Service Functions must apply to
the traffic flow. This is discussed in more detail in section
2.4.
2.3. Avoiding repeated execution of expensive operations
Certain types of information are computationally expensive to
extract from the traffic flow.
For example, it is computationally expensive to perform Deep Packet
Inspection (DPI) because the TCP stream may have to be reconstructed
and sophisticated layer-7 pattern matching algorithms must be
applied.
If multiple Service Functions need the same information, it is more
efficient to perform the computationally expensive operation (e.g.
DPI) only once and to share the result with other Service Function
in Service Function Chain using metadata.
As a concrete example of a use case that can benefit from not
performing the same expensive operation more than once, we consider
some examples of Service Functions which could benefit from the
availability of metadata (namely an Application-ID) provided by a
DPI Service Function earlier in the Service Function Chain.
A caching Service Function may only want to attempt to cache YouTube
video traffic but not Netflix video traffic.
A firewall Service Function for a human resources department may
want to block Facebook games but allow other type of Facebook
traffic.
A WAN optimization Service Function may want to optimize database
synchronization traffic but not video conference streaming.
Rijsman, et al. Expires August 12, 2014 [Page 5]
Internet-Draft Metadata Considerations February 2014
Each of these Service Functions needs to know what type of
application layer traffic is carried in each traffic flow.
Rather than repeatedly doing DPI at each Service Function (at the
cache, the firewall, and the WAN optimizer) we can do DPI once and
associate the resulting Application-ID as metadata with the traffic
flow.
2.4. Fine-grained policies
For coarse-grained policies, i.e. if the number of policies is
small, it is feasible to create a separate Service Function Chain
for each policy. The Service Classifier can apply the correct
policy to each traffic flow by steering that traffic flow into the
corresponding Service Function Chain.
As a concrete example, consider a scenario with two Service
Functions: a firewall and a cache. Some traffic flows only visit
the firewall, some traffic flows visit only the cache, and some
traffic flows visit both the firewall and the cache. This can be
implemented by creating three separate Service Function Chains:
.------------.
/ \
,------. / ,------. \
-------/ \--' / \ '-----> SFC-1: only firewall
------( firewall )-----( NAT )---------> SFC-2: firewall + NAT
--. \ / .--\ /----------> SFC-3: only NAT
\ `------' / `------'
\ /
'------------'
Figure 1: Combinations of Service Functions
As the number of Service Functions increases, the number of possible
combinations an permutations increases exponentially. Hence, it may
not be feasible or efficient to create separate Service Function
Chains.
Furthermore, it may be necessary to apply different service policies
to different traffic flows which visit the same sequence of Service
Functions.
For example, the firewall may block certain websites for one traffic
flow and other websites for a different traffic flow.
Rijsman, et al. Expires August 12, 2014 [Page 6]
Internet-Draft Metadata Considerations February 2014
One way of implementing this is to create a separate Service
Function Chain for each unique combination of service policies.
In the following example we have three Service Function Chains which
all visit a firewall and a throttle service. The Service Function
Chain implicitly determines which service policy is applied at the
firewall and at the throttle service. For example, the third Service
Function Chain (SFC-3) receives blocks Facebook at the firewall and
is limited to 30 Mbps at the throttle service:
,------. ,------.
-----/ \-----/ \-----> SFC-1: block YouTube + 20 Mbps
----( firewall )---( throttle )----> SFC-2: block Facebook + 20 Mbps
-----\ /-----\ /-----> SFC-3: block Facebook + 30 Mbps
`------' `------'
Figure 2: Combinations of service policies
Once again, as the number of service policies increases at each
Service Function, the number of possible combinations of service
policies increases exponentially. Hence, it may not be feasible or
efficient to create separate Service Function Chains.
This problem is aggravated when the service policies become more
"fine grained". For example, in the example in figure 2 above we
only have two possible values for the bandwidth namely 20 Mbps or 30
Mbps. Consider what would happen if we had ten or more possible
bandwidth values: the number of possible service policies
combinations would suffer a combinatorial explosion.
In the extreme case, if each customer could have his own individual
bandwidth limit, this would imply a Service Function Chain for each
individual customer.
Instead of creating separate Service Function Chains, we can use
metadata to signal the fine grained policy information. The
metadata can identify which service policy needs to be applied at
each Service Function, and the metadata can carry fine grained
service policy parameters (such as the bandwidth in the above
example) in the form of parameter values for a policy profile or
policy template.
There is a trade-off between simplicity and flexibility. If the
operator provides a small number of uniform network services, then
the simple approach of using one Service Function Chain per network
service suffices and no fine grained policy metadata is needed. On
Rijsman, et al. Expires August 12, 2014 [Page 7]
Internet-Draft Metadata Considerations February 2014
the other hand, if the number of unique network services is large or
variable (i.e. dependent on the subscriber) then the additional
complexity of fine grained policy metadata is justified by the
additional flexibility it provides.
3. Metadata signaling approaches
This section describes various approaches for signaling metadata.
3.1. In-band marking
The metadata can be transferred by attaching a metadata field to
each packet which traverses the Service Function Chain.
In this draft we refer to this "in-band" marking because the
metadata and the data are carried in the same communications
channel, i.e. stored in the same packet.
+----------+------+
| Metadata | Data |
+----------+------+
.
.
,---. ,---. . ,---.
/ \ / \ V / \
=====>( SF1 )====>( SF2 )=====>( SF3 )=====> SFC
\ / \ / \ /
`---' `---' `---'
Figure 3: Metadata in each packet
The metadata may simply be attached to each data packet as shown
above. Or, the extra field which is attached to each packet may be
used to implement a more sophisticated protocol in which case it
would be more appropriate to speak of in-band signaling instead of
in-band marking. There is a fine line between in-band signaling and
congruent out-of-band signaling which is discussed in section 3.3.
The figure above is purposely vague on where exactly in the data
packet the metadata is carried. There are several options:
The field which carries the metadata can be a new field which is
introduced specifically for the purpose of carrying metadata. The
Network Service Header (NSH) described in [draft-quinn-sfc-nsh] is
an example of this approach.
Rijsman, et al. Expires August 12, 2014 [Page 8]
Internet-Draft Metadata Considerations February 2014
Alternatively, the field can be an existing field such as a new IPv4
option or a new IPv6 extension header. This has the advantage of
minimizing the impact on existing routers, switches, hosts, and
applications; they are able to receive and forward packets with
options or extension headers which they do not understand.
Note that the presence of IPv4 options or IPv6 extension headers may
cause the packets to be processed in the so-called "slow path" of
some core routers instead of the fast path and hence impair
forwarding performance.
3.2. Metadata in application layer headers
Another approach is to carry metadata in the headers of application-
layer messages.
This approach works well the Hypertext Transfer Protocol (HTTP)
[RFC2616] where it easy to introduce new header fields into
messages.
Hypothetically, this approach can also be done with similar text-
based protocols such as the Simple Mail Transfer Protocol (SMTP)
[RFC5321] or the Real Time Streaming Protocol (RTSP) [RFC2326],
although in practice it is mostly used with HTTP. This approach
does not work well with binary application layer protocols.
Only Service Functions which process traffic at the application
layer (e.g. parse HTTP) have access to this kind of metadata.
Routers and switches and Service Functions which process traffic at
layer 1 through 4 do not have access to the metadata. This is not
necessarily always a disadvantage - the expense of parsing the
metadata is incurred only at the places which need it.
Rijsman, et al. Expires August 12, 2014 [Page 9]
Internet-Draft Metadata Considerations February 2014
HTTP Request
+--------------------------------------------+
| GET / HTTP/1.1 |
| Host: www.google.com |
| Connection: keep-alive |
| Cache-Control: max-age=0 |
| Accept: text/html,application/xhtml+xml |
| User-Agent: Mozilla/5.0 (Windows NT 6.1) |
| Accept-Encoding: gzip,deflate |
| Accept-Language: en-US,en;q=0.8 |
| Metadata-Subscriber-ID: 12345 | \ Metadata
| Metadata-Application-ID: 67890 | /
+--------------------------------------------+
.
.
,---. ,---. . ,---.
/ \ / \ V / \
=====>( SF1 )====>( SF2 )=====>( SF3 )=====> SFC
\ / \ / \ /
`---' `---' `---'
Figure 4: Metadata in HTTP headers
The above example uses hypothetical non-standard headers
Metadata-Subscriber-ID and Metadata-Application-ID to carry the
metadata. [RFC2774] defines an HTTP extension framework (which is
not used in this example) for introducing new HTTP headers. The
practice of prefixing non-standard headers with X- has been
deprecated by [RFC6648].
3.3. Congruent out-of-band metadata signaling
Metadata can be signaled using a congruent out-of-band control plane
protocol.
"Out-of-band signaling" means that the data plane and the control
plane for signaling the metadata are carried in different
communication channels (i.e. different packets). This is opposed to
"in-band marking" which means that the data and metadata are carried
in the same communication channel (i.e. in the same packet as
discussed in section 3.1. ).
"Congruent" means that the data plane protocol and the control plane
protocol follow the same path through the network.
Rijsman, et al. Expires August 12, 2014 [Page 10]
Internet-Draft Metadata Considerations February 2014
The classical example of a congruent out-of-band protocol is the
File Transfer Protocol (FTP) [RFC959] which has separate data and
control connections, but they follow the same path through the
network.
+----+ ,---. Metadata ,---. ,---.
| |---->/ \--------->/ \------->/ \
| SC | ( SF1 ) ( SF2 ) ( SF3 )
| |====>\ /=========>\ /=======>\ /======> SFC
+----+ `---' Data `---' `---'
router
Figure 5: Congruent out-of-band metadata signaling
With congruent out-of-band control plane signaling, the router at
the head of the service chain sends control plane messages to the
first Service Node (SN) in the Service Function Chain to associate
metadata with a particular traffic flow. The Service Node makes the
metadata available to the Service Function to consume. The Service
Function also has the opportunity to add or modify metadata. The
Service Node then uses control plane signaling to propagate the new
metadata for the traffic flow to the next Service Node. Etcetera.
New control plane protocols could be introduced for the congruent
out-of-band metadata signaling, or existing protocols such as the
Layer 2 Tunneling Protocol (L2TP) [RFC2661,RFC3931], or the Resource
Reservation Protocol (RSVP) [RFC2205] could be extended to do
metadata signaling.
3.4. Non-congruent out-of-band metadata signaling
Metadata can be signaled using a non-congruent out-of-band control
plane protocol, separate from the data plane protocol which carries
the packets through the Service Function Chain.
"Non-congruent" means that the data plane protocol and the control
plane protocol follow different paths through the network.
A classic example of a non-congruent out-of-band protocol is an
Interior Border Gateway Protocol (IBGP) [RFC4271] session to a route
reflector: the BGP session and the data traffic can follow
completely different paths through the network.
Rijsman, et al. Expires August 12, 2014 [Page 11]
Internet-Draft Metadata Considerations February 2014
+------------------------------------------------+
| Metadata signaling control plane |
+------------------------------------------------+
^ | | |
| | Metadata | |
| v v v
+----+ ,---. ,---. ,---.
| | / \ / \ / \
| SC |=====>( SF1 )====>( SF2 )=====>( SF3 )=====> SFC
| | \ / Data \ / \ /
+----+ `---' `---' `---'
router
Figure 6: Non-congruent out-of-band metadata signaling
The control plane could consist of a request-response model where
the Service Functions explicitly request the metadata when a traffic
flow is first observed.
New control plane protocols could be introduced for the non-
congruent out-of-band metadata signaling, or existing protocols such
as Remote Authentication Dial In User Service (RADIUS) [RFC2865],
Diameter [RFC6733], or the Session Initiation Protocol (SIP)
[RFC3261] could be extended to do metadata signaling.
Alternatively, the control plane could consist of a publish-
subscribe ("pub-sub") message bus. Any Service Function in the
Service Function Chain or the router at the start of the Service
Function Chain can publish metadata for individual traffic flows.
Any Service Function in the Service Function chain can create a
subscription to receive metadata for traffic flows. The
subscription can include a filter to receive only specific type of
metadata of interest to the Service Function.
One could use a pub-sub message bus such as ZeroMQ [zeromq.org] or a
pub-sub database such as Redis [redis.io].
3.5. Hybrid in-band marking and out-of-band signaling
Metadata can be signaled using a hybrid approach combining in-band
marking and out-of-band signaling.
Each data packet can carry a small fixed-length field which serves
as a "correlator". An out-of-band signaling protocol can then be
used to map the correlator value to the actual metadata value(s).
Rijsman, et al. Expires August 12, 2014 [Page 12]
Internet-Draft Metadata Considerations February 2014
The correlator field is typically a form of session identifier; we
will use the term Session-ID in this draft. All data packets with
the same Session-ID belong to the same session.
The concept of a correlator field is very similar to the concept of
a Forwarding Equivalence Class (FEC) which defines a group of
packets which need to be treated in the same way.
+------------------------------------------------+
| Metadata signaling control plane |
+------------------------------------------------+
^ ^ | ^ | ^ |
|Session-ID | | Session-ID| |Metadata | |
|+ Metadata | v | v | v
+----+ ,---. ,---. ,---.
| | / \ / \ / \
| SC |======>( SF1 )=====>( SF2 )=====>( SF3 )=====> SFC
| | \ / ^ \ / \ /
+----+ `---' . `---' `---'
router .
+------------+------+
| Session-ID | Data |
+------------+------+
Packet
Figure 6: Hybrid in-band marking and out-of-band metadata signaling
The Layer 2 Tunneling Protocol (L2TP) [RFC2661,RFC3931] and the
General Packet Radio System Tunneling Protocol (GTP) [GTP] are both
examples of hybrid protocols. Each has a data plane protocol (GTP-U
in the case of GTP) which carries a Session-ID. The Session-ID is
used as a correlator to a separate control plane protocol (GTP-C in
the case of GTP).
4. Metadata challenges
This section discusses the challenges associated with metadata.
4.1. Support for metadata-unaware Service Functions
There is already a large number of Service Functions on the market
such as firewalls, load balancers, WAN optimizers, caches, DDoS
mitigation, etc. These existing Service Functions are available in
both physical form and virtual form.
Rijsman, et al. Expires August 12, 2014 [Page 13]
Internet-Draft Metadata Considerations February 2014
Since metadata has not yet been standardized, the existing Service
Functions generally don't understand how to extract and process
metadata. They generally expect to receive and send normal IP over
Ethernet packets, possibly with a VLAN tag. We refer to such
Service Functions as being metadata-unaware.
If the IETF defines a new type of encapsulation header specifically
for the purpose of carrying metadata, it will not be possible to
inject packets with the new metadata header into existing
metadata-unaware Service Functions. Such packets would be dropped
because the new encapsulation is not recognized.
Thus, for backwards compatibility it will be required to strip any
new metadata headers from the packet before it is injected into a
metadata-unaware Service Function.
One possible implementation choice is to always strip the metadata
from the packet before injecting it to any Service Function, both
metadata-aware and metadata-unaware Service Functions. The
metadata-aware Service Functions could choose to retrieve the
metadata, for example by calling an API (e.g. a socket call) to
retrieve the metadata.
The other approaches (i.e. other than introducing a new header for
metadata) can handle metadata-unaware Service Functions more easily.
Existing Service Functions are able to ignore new HTTP headers.
Many existing HTTP-aware Service Functions can be configured to
recognize specific HTTP headers, even non-standard HTTP headers, and
take specific actions based on the presence or value of specific
HTTP headers.
Existing Service Functions are able to ignore new IPv4 options or
new IPv6 extension headers. However, most existing Service
Functions can NOT be configured to take action based on the presence
or value of a specific option or extension header.
If an out-of-band control plane protocol is used to signal metadata,
metadata-unaware Service Functions can ignore the metadata by simply
not participating in the control plane protocol.
4.2. Preserving metadata through metadata-unaware Service Functions
As described in the previous section, there are ways to support a
metadata-unaware Service Function in a Service Function Chain, at
least in the sense that the metadata-unaware Service Function will
not choke on the traffic flow. The metadata-unaware Service
Rijsman, et al. Expires August 12, 2014 [Page 14]
Internet-Draft Metadata Considerations February 2014
Function will see what appears to be a completely normal IP over
Ethernet traffic flow (possibly with a VLAN tag).
However, there is another problem. The metadata should be preserved
when it passes through a metadata-unaware Service Function.
Consider, for example, a scenario where the metadata is stripped
from the packet before the packet is injected into a metadata-
unaware Service Function. For Virtual Service Functions running in
a virtual machine, the metadata is typically stripped in the virtual
switch (vSwitch) or virtual router (vRouter) in the hypervisor of
the virtualized server. For Physical Service Functions running on
hardware, the metadata is typically stripped in the proxy node
(sometimes called gateway node) in front of the Physical Service
Function.
Now imagine there is a subsequent Service Function later in the
Service Function Chain which is metadata-aware. In this case we
need to re-attach the metadata to the packet after it leaves the
metadata-unaware Service Function and before it reaches the
metadata-aware Service Function.
Clearly, the metadata-unaware Service Function cannot re-attach the
metadata because it is, by definition, not aware of the existence of
the metadata.
At first sight, it seems reasonable to expect the vSwitch or vRouter
or proxy node which stripped the metadata to also re-attach the
metadata. In practice, however, this is extremely difficult to
implement. The algorithm for stripping and re-attaching the
metadata would look something like this:
1. For every received packet P do the following
2. Strip the metadata from P
3. Store the stripped metadata
4. Inject the packet into metadata-unaware Service Function F
5. Service Function F receives the packet P
6. Service Function F processes packet P
7. Service Function F sends packet P
8. Retrieve the stored metadata for packet P
Rijsman, et al. Expires August 12, 2014 [Page 15]
Internet-Draft Metadata Considerations February 2014
9. Re-reattach the metadata to packet P
10. Send packet P
This seems simple enough but there are two major problems.
The first problem is in steps 3 and 8. What is the key which we use
to store and retrieve the stored metadata? For every given flow,
there are going to be many packets P1, P2, ..., Pn which have
exactly the same Ethernet source and destination address, the same
IP source and destination address, the same protocol ID, the same
TCP source and destination port etc. However, packets P1, P2, ...,
Pn may have different metadata. Furthermore, certain Service
Functions such as Network Address Translation (NAT) and HTTP Proxies
change the source or destination addresses or ports of the packets.
The second problem is in steps 5, 6 and 7. There is an implicit
assumption that Service Function F sends exactly one packet P for
every received packet P. In reality, this is not a valid
assumption. Service Function F may drop packets, re-order packets,
duplicate packets, insert new packets, or even completely change the
traffic flow including the addresses (e.g. a proxy).
A similar problem occurs for metadata which is stored in an existing
header such as an IPv4 option or an IPv6 extension header. In this
case it is not necessary to strip the metadata from the packet
before it is injected into the metadata-unaware Service Function.
However, the metadata is typically lost when it traverses the
metadata-unaware Service Function. Existing Service Functions on
the market are often implemented by opening a pair of sockets,
reading packets from one socket, processing the packets, and sending
the packets on the other socket. Typically implementations using
socket APIs do not preserve IPv4 options or IPv6 extension headers.
How can we deal with this problem?
One possible approach is to simply accept that the metadata is lost
once the traffic flow visits a metadata-unaware Service Function.
Any subsequent Service Functions in the Service Function Chain do
not have access to the metadata anymore.
Another possible approach is to introduce the restriction that if a
Service Function Chain contains at least one metadata-aware Service
Function, then all Service Functions in the Service Function Chain
must be metadata-aware.
Rijsman, et al. Expires August 12, 2014 [Page 16]
Internet-Draft Metadata Considerations February 2014
A third possible approach is to modify the Service Function
implementation to retrieve and maintain the metadata. That is just
a different way of saying that all Service Function should be
metadata-aware which will take time.
Some of the other approaches (i.e. other than storing the metadata
in the same packet as the data) can more easily preserve metadata as
it passes through a metadata-unaware Service Function.
All HTTP headers, even unrecognized HTTP headers, are generally
preserved when they pass through a Service Function.
The control plane based approaches can simply skip the metadata
unaware service. For non-congruent out-of-band metadata signaling
this is trivial. For congruent out-of-band metadata signaling this
is also easy, but care must be taken that the control plane does not
run in the Service Function itself but in the vSwitch or vRouter or
proxy node 'below' the Service Function.
4.3. Metadata encoding
There is a tradeoff between flexibility and performance when making
a decision on how to encode metadata.
We can use a fixed number of metadata fields or a variable number of
metadata fields.
Each metadata field can have a fixed length format or a variable
length format.
We can support a fixed set of metadata field types, or we can
support an extensible framework where different vendors and users
can introduce new metadata field types using some sort of allocation
mechanism.
Clearly, supporting a variable number of metadata fields, each with
a variable length, each with a different syntax, and with some
registration mechanism to introduce new metadata types provides the
most flexibility and extensibility.
Such flexibility and extensibility is perfectly feasible for some
approaches, namely when we carry metadata in HTTP header, or when we
use extensible out-of-band signaling protocols such as Diameter.
However, when the metadata is attached to each packet (either in a
new header or in an existing field such as an IPv4 option or an IPv6
Rijsman, et al. Expires August 12, 2014 [Page 17]
Internet-Draft Metadata Considerations February 2014
extension header), flexibility and extensibility come at such a high
cost that it is not practical.
When metadata is attached to a packet it must still be possible to
forward packets in the fast path of a router or switch. It is very
difficult and expensive to deal with variable-length encoding and
with fields with an unbounded length in hardware. At first sight,
this is not a problem because the metadata can be stored behind the
Ethernet header and the IP header. However, in practice it is a
problem. The fast path must often look deeper into the packet for
Access Control Lists (ACLs), Quality of Service (QoS), firewalling,
tunnel decapsulation, etc.
4.4. Scalability and performance of the control plane
Scalability and performance of the control plane is a concern when
we use out-of-band metadata signaling.
Typically there will be at least one control plane message exchange
for every new traffic flow or for every new session which passes
through a service chain to associate metadata with that traffic
flow. The rate at which traffic flows or sessions appear and
disappear can be very high: thousands per second or more. This
requires a very high performance control plane. The number of
simultaneously active traffic flows or sessions, each with its own
state, can be very high: millions or more. This requires a very
scalable control plane.
The control plane interaction also causes extra latency for the data
plane traffic.
4.5. Synchronization between the control plane and the data plane
In the out-of-band signaling based approaches, the data and the
metadata are carried over separate communication channels. The data
is carried over a data plane channel, and the metadata is carried
over a control plane channel.
The data and the metadata for a new flow do not arrive
simultaneously at a Service Function. The data may arrive before
the metadata, or the other way around.
As a result, the Service Function may have to buffer the data
packets while waiting for the metadata to arrive. This requires
stateful processing of traffic flows which is difficult and
expensive to implement in hardware. Also, the memory for the
additional buffers increases the cost.
Rijsman, et al. Expires August 12, 2014 [Page 18]
Internet-Draft Metadata Considerations February 2014
Alternatively, the Service Function may simply drop the data while
waiting for the corresponding metadata, relying on the application
layer to retransmit the data. This increases latency and decreases
end-user perceived quality.
The delay and buffering problem is aggravated for non-congruent out-
of-band signaling (compared to congruent out-of-band signaling)
because the control plane uses a different path for the control
plane which is typically much slower than the data plane path
because it uses slower interfaces and passes through intermediate
control plane nodes.
4.6. Distributing metadata only to interested Service Functions
It is highly desirable that metadata is only signaled to those
Service Functions which actually need it.
In other words, ideally a Service Function should only receive:
o Metadata for those traffic flows which actually visit that
instance of the Service Function. For example, if a Service
Function Chain contains multiple parallel scale-out instances of
a firewall, each firewall should only receive metadata for the
traffic flows which actually pass through that instance of the
firewall.
This is easy to achieve with in-band marking and with congruent
out-of-band signaling. With non-congruent out-of-band signaling
is also easy to achieve if a "pull" model is used, but it is non-
trivial to achieve if a "publish" model is used.
o Metadata which is of interest to that particular Service
Function. For example is a Service Function chain contains a
sequence of a firewall and a cache, then the firewall should only
achieve the metadata which of interest to the firewall and the
cache should only receive the metadata which is of interest to
the cache. There could of course also be metadata which is of
interest to both the firewall and the cache.
This is easy to achieve with non-congruent out-of-band signaling.
It is more difficult to achieve with in-band marking and with
congruent out-of-band signaling.
Rijsman, et al. Expires August 12, 2014 [Page 19]
Internet-Draft Metadata Considerations February 2014
4.7. Associating data plane flows with control plane signaling
If we use out-of-band control plane signaling for metadata, there
must be a way to associate a control plane message with a data plane
flow.
There will be a control plane message which says "use metadata M for
traffic flow F" or some variation thereof.
The question is: how is traffic flow F identified?
A seemingly obvious answer is to use the 5-tuple (source IP,
destination IP, protocol, source port, destination port) of the flow
or some subset of the 5-tuple.
This approach is thwarted by the fact that many (possibly most)
service chains contain one or more services which modify the 5-
tuple, such as for example Network Address Translation (NAT) or HTTP
proxies.
One possible approach is to use the IPv6 flow label field.
Unfortunately, there is not standard flow label field for IPv4.
Plus, existing Service Functions are not likely to preserve the flow
label as discussed in section 4.2.
Another possible approach is to use an approach which is a hybrid
between the in-band marking approach and the out-of-band signaling
approach as described in section 3.5.
4.8. Layering considerations
As described in [draft-quinn-sfc-nsh] Service Function Chains
consists of one or more parallel Service Paths.
Each Service Path consists of a concatenation of Service Functions
which are connected by Service Path Segments. These Service
Functions may be Virtual Service Functions on Service Nodes. Or,
they may be Physical Service Functions connected to proxies or
gateways.
The Service Classifier at the head of the Service Function Chain
perform load balancing by steering each traffic flow in the chosen
Service Path.
Rijsman, et al. Expires August 12, 2014 [Page 20]
Internet-Draft Metadata Considerations February 2014
. .
.<~~~~~~~~~~~~ Service Function Chain ~~~~~~~~~~~>.
. .
. +- Service Path Segment .
. | .
. +----------------+ | +--------------+ .
. | Service Node 1A| | | SN2A | .
+------+ | ,-------. | | | ,----. | .
| | | / Service \ | v | / \ | .
| ,----->( Function )------->( SF2A )----. <~~~~~ Service
| / | | \ SF1A / | | \ / | \ . Path
| / | | `-------' | | `----' | \ .
| / | +----------------+ +--------------+ \ .
---< | >--->
| \ | +----------------+ /
| \ | | ,-------. | +--------------+ /
| \ | | / \ | | Proxy | /
| `----->( SF1B )-------> or ---'
| | | \ / | | Gateway |
+------+ | `-------' | +--------------+
Service | SN1B | | |
Classifier +----------------+ +--------------+
| Physical |
| Service |
| Function SF2B|
+--------------+
Figure 7: Service Function Chains, Paths, and Path Segments
It is useful to think of this architecture in terms of layers:
1. The service function layer is responsible for performing the
service at each Service Function and for steering the packets
into the right Service Path.
2. The service path layer is responsible for transporting data
packets from one Service Function to the next Service Function in
the Service Path.
3. The traditional network layer provided by the underlay network is
responsible for forwarding packets from Service Node to Service
Node.
Rijsman, et al. Expires August 12, 2014 [Page 21]
Internet-Draft Metadata Considerations February 2014
.................
. Service Node .
. .
+-----------+ . +-----------+ . +-----------+ \
| Service | . | Virtual | . | Physical | | Service
| Classifier| . | Service | . | Service | | Function
| | . | Function | . | Function | | Layer
| | . +-----------+ . +-----------+ /
| | . | | . | |
| | . +-----------+ . +-----------+ \
| | . | vSwitch | . | Proxy | | Service
| |===========| or |=====| or |== | Path
| | Overlay . | vRouter | . | Gateway | | Layer
+-----------+ Tunnel . +-----------+ . +-----------+ /
| ........|........ |
| | |
+-----------+ +-----------+ +-----------+ \
| Underlay | | Underlay | | Underlay | | Network
| Switch or |-----------| Switch or |-----| Switch or |-- | Layer
| Router | | Router | | Router | |
+-----------+ +-----------+ +-----------+ /
Figure 8: Layers
In the service path layer, each Service Path Segment is typically
implemented using some sort of overlay tunnel.
The overlay tunnel can be implemented in various ways, including
Virtual Local Area Networks (VLANs) [802.1Q], Virtual Extensible
Local Area Networks (VXLANs) [draft-mahalingam-dutt-dcops-vxlan],
Generic Route Encapsulation (GRE) [RFC2784] tunnels, or Label
Switched Paths (LSPs) [RFC3031].
At the end of each Service Path segment there is some entity which
decapsulates the packets from the overlay tunnel and dispatches the
packets into the right Service Function. For Virtual Service
Functions may be a virtual switch (vSwitch) or virtual router
(vRouter). For Physical Service Functions this may be a proxy or
gateway.
The tunnel encapsulation needs a field to identify the Service Path
Segment. The vSwitch or vRouter or proxy or gateway uses this field
to dispatch each packet into the correct Service Function. This
field can be implemented in multiple ways, including a VLAN tag, a
Virtual Network Identifier (VNID) in the VXLAN header, a Multi-
Protocol Label Switching (MPLS) label, or the service path field in
Rijsman, et al. Expires August 12, 2014 [Page 22]
Internet-Draft Metadata Considerations February 2014
the base service header of the Network Service Header
[draft-quinn-sfc-nsh].
In addition to the field which identifies the Service Path as just
discussed, there may be more fields in the packet which contain
additional metadata such for example as the Session-ID or the
Accounting-ID.
These additional metadata fields are only relevant in the service
function layer. They are attached by the Service Classifier. They
are read and acted upon by the Service Functions. The vSwitches,
vRouters, proxies, or gateways never need to read or write this
additional metadata.
Thus, it is important to make a distinction between fields which are
used at the service path layer to identify the Service Path Segment,
and additional fields which carry metadata which is imposed and
interpreted at the service function layer. Combining both types of
fields into a single header should probably be avoided from a
layering point of view.
The need for such separation is reinforced by the existence of
various ways to convey metadata that were discussed in chapter 3.
It isn't necessarily obvious that packet marking is the best way to
implement the service function layer.
4.9. Load balancing and symmetry
In a scaled-out service, i.e. when the Service Function Chain
consists of more than one Service Path, load balancing is used to
assign each traffic flow to exactly one of the available Service
Paths.
Often the Service Functions in a Service Function chain are
"stateful" and as a result they may need to see all packets in a
flow in both directions. In that case, the forward and the reverse
traffic flow must be assigned to the same Service Path, i.e. load
balancing must be symmetric. (This is actually difficult to achieve
when the different Service Paths terminate on different Service
Nodes, but that discussion is beyond the scope of this draft.)
The metadata signaling protocol must ensure that the metadata for a
given traffic node is signaled to the same Service Path (i.e. the
same set of Service Nodes) which process the data for that traffic
flow. Ideally, the metadata is not signaled to any other Service
Nodes, i.e. not signaled to places where it is not needed.
Rijsman, et al. Expires August 12, 2014 [Page 23]
Internet-Draft Metadata Considerations February 2014
This is easy to achieve when the metadata is attached to the data
and it is also easy to achieve with congruent out-of-band signaling.
It is more challenging to achieve for non-congruent out-of-band
signaling, particularly in a pub-sub model.
4.10. High availability and geographic dispersion
Any kind of construct requiring high-rate out-of-band communication
with a policy or signaling server is subject to all sorts of
challenges if said server is suddenly no longer reachable (not
necessarily a crash, but a simple connectivity loss). In other
words, one has to factor in the geographical distribution of the
problem.
In the non-congruent out-of-band signaling approach there may be
logically centralized servers (e.g. RADIUS or Diameter servers) that
communicate with the Service Nodes and the Service Classifiers.
The Service Nodes and Service Classifiers may be geographically
dispersed. A single Service Function Path may visit Service
Functions which are located in a central office, a distributed
regional data/service center, and a more centralized data/service
center.
Using a single (logical) server to control all geographic locations
introduces challenges from a scaling and high availability
perspective.
Using multiple (logical) servers improves scalability and reduced
the size of failure domains, but introduces complexity because the
servers must use federation protocols for coordination.
4.11. Multiple sources of metadata
In simple use cases it may be sufficient for all metadata to be
produced and associated with the traffic flow once at the start of
the service chain.
On more sophisticated use case it may be useful to allow Service
Functions in the Service Function Chain to associate additional
metadata with a traffic flow as the data traverses the service
chain.
In the latter case, the signaling mechanism must support multiple
sources of metadata.
Rijsman, et al. Expires August 12, 2014 [Page 24]
Internet-Draft Metadata Considerations February 2014
4.12. Extensibility
The metadata mechanism must be extensible.
As new Service Functions are introduced, it must be possible for to
introduce new types of metadata using some sort of registration
process.
The extension mechanism must support backward compatibility: it must
be possible to distribute a new type of metadata in a Service Chain
which includes some Service Functions that do not understand the new
type of metadata.
Extensibility is particularly important for the service function
layer, more so than for the service path layer (see section 4.8. for
layering).
5. Conclusion
In this draft we discussed several metadata signaling approaches:
o In-band marking
o Metadata in application layer headers
o Congruent out-of-band metadata signaling
o Non-congruent out-of-band metadata signaling
o Hybrid in-band marking and out-of-band signaling
We also discussed metadata signaling challenges:
o Support for metadata-unaware service function
o Preserving metadata through metadata-unaware service functions
o Metadata encoding
o Availability and performance of the control plane
o Synchronization between the control plane and the data plane
o Distributing metadata only to interested service functions
Rijsman, et al. Expires August 12, 2014 [Page 25]
Internet-Draft Metadata Considerations February 2014
o Associating data plane flow with control plane signaling
o Layering considerations
o Load balancing and symmetry
o High availability and geographic dispersion
o Multiple sources of metadata
o Extensibility
We also discussed how each of the signaling approaches was affected
by each of the challenges.
The problem of signaling metadata is complex. Whatever signaling
approach is chosen multi-vendor interoperability is required, hence
the need for standardization.
In general, it is desirable to solve simple problems with simple
solutions and to make more complex solutions and mechanisms
optional.
A productive path forward could be to divide and conquer: to clearly
separate the problem of Service Function Path topology from the
problem of metadata. In other words, to make a clear distinction
between what we called the service path layer and the service
function layer in section 4.8.
The Service Function Chaining working group could initially focus on
the service path layer, i.e. the mechanism for steering packets
through the right sequence of Service Functions in the Service Path.
Conveying contextual metadata could be viewed as optional, and not
applicable to all service chains. Furthermore, the means to address
the needs of the service function layer aren't necessarily the same
as those required for the service path layer.
In this draft shy away from recommending one of the approaches as
the best approach of all use cases. Different approaches may make
sense for different use cases.
Rijsman, et al. Expires August 12, 2014 [Page 26]
Internet-Draft Metadata Considerations February 2014
6. Security Considerations
The metadata signaling protocol must be secure in the sense that the
authenticity (i.e. the validity of the content) and the authority
(i.e. the source) must be guaranteed. Non-renumeration (i.e.
encryption) of the metadata may or may not be a requirement.
7. IANA Considerations
None.
8. References
8.1. Normative References
None.
8.2. Informative References
[802.1Q] IEEE Std. 802.1Q-2011, Media Access Control (MAC) Bridges
and Virtual Bridged Local Area Networks.
[draft-mahalingam-vxlan] M. Mahalingam, et al. "VXLAN: A Framework
for Overlaying Virtualized Layer 2 Networks over Layer 3
Networks.", draft-mahalingam-dutt-dcops-vxlan-08, February
3, 2014.
[draft-quinn-sfc-arch] P. Quinn, at al, "Service Function Chaining
(SFC) Architecture", draft-quinn-sfc-arch-04, January 28,
2014.
[draft-quinn-sfc-nsh] P. Quinn, et al, "Network Service Header",
draft-quinn-sfc-nsh-00, April 10, 2014.
[GTP] 3GPP TS 32.295 V6.1.0 (2005-06), 3rd Generation Partnership
Project.
[in-band-control] Wikipedia, "In-band control",
http://en.wikipedia.org/wiki/In-band_control
[out-of-band-control] Wikipedia, "Out-of-band control",
http://en.wikipedia.org/wiki/Out-of-band_control
[redis.io] "Redis website", http://redis.io
[RFC959] J. Postal and J. Reynolds. "File Transfer Protocol (FTP)",
RFC959, October 1985.
Rijsman, et al. Expires August 12, 2014 [Page 27]
Internet-Draft Metadata Considerations February 2014
[RFC1661] W. Simpson, et al. "The Point-to-Point Protocol (PPP)",
RFC1661, July 1994.
[RFC2205] R. Braden, et al. "Resource ReSerVation Protocol",
RFC2205, September 1997.
[RFC2326] H. Schulzrinne, et el. "Real Time Streaming Protocol
(RSTP)", RFC2326, April 1998.
[RFC2616] R. Fielding, et al. "Hypertext Transfer Protocol --
HTTP/1.1", RFC2616, June 1999.
[RFC2661] W. Townsley, et al. "Layer Two Tunneling Protocol L2TP",
RFC2661, August 1999.
[RFC2774] H. Nielsen, et al. "An HTTP Extension Framework", RFC2774,
February, 2000.
[RFC2784] D. Farinacci, et al. "Generic Route Encapsulation (GRE)",
RFC2784, March 2000.
[RFC2865] C. Rigney, et al. "Remote Authentication Dial In User
Service (RADIUS)", RFC2865, June 2000.
[RFC3031] E. Rosen, et al. "Multiprotocol Label Switching
Architecture", RFC3031, January 2001.
[RFC3261] J. Rosenberg, et al. "SIP: Session Initiation Protocol",
RFC3261, June 2002.
[RFC3931] J. Lau, et al. "Layer Two Tunneling Protocol - Version 3
(L2TPv3)", RFC3931, March 2005.
[RFC4271] Y. Rekhter, et al. "A Border Gateway Protocol 4 (BGP-4)",
RFC4271, January 2006.
[RFC5321] J. Klensin. "Simple Mail Transfer Protocol", RFC5321,
October 2008.
[RFC6648] P. Saint-Andre, et al. "Deprecating the "X-" Prefix and
Similar Constructs in Application Protocols", RFC6648,
June, 2012
[RFC6733] V. Fajardo, et al. "Diameter Base Protocol", RFC6733,
October 2012.
[zeromq.org] "ZeroMQ website", http://zeromq.org
Rijsman, et al. Expires August 12, 2014 [Page 28]
Internet-Draft Metadata Considerations February 2014
9. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
The authors thank Ross Callon, Sankar Ramamoorthi, Gary Greenberg,
Galina Pildush, Jaspal Kohli, Stuart Mackie, and James Connolly for
their review and comments.
Rijsman, et al. Expires August 12, 2014 [Page 29]
Internet-Draft Metadata Considerations February 2014
Authors' Addresses
Bruno Rijsman
Juniper Networks
brijsman@juniper.net
Jerome Moisand
Juniper Networks
jmoisand@juniper.net
Rijsman, et al. Expires August 12, 2014 [Page 30]
