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]