Network Working Group H. Zhang
Internet-Draft L. Fourie
Intended Status: Proposed Standard Huawei
R. Parker
Affirmed Networks
M. Zarny
Goldman Sachs
Expires: September 25, 2014 March 24, 2014
Service Chain Header
draft-zhang-sfc-sch-00
Abstract
This document describes a service chaining header format and
encapsulation mechanism that is used to facilitate the forwarding of
data packets along the service function chain path. This header also
allows for the transport of metadata to support various service chain
related functionality.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
Zhang, et al Expires September 25, 2014 [Page 1]
Internet-Draft Service Chain Header March 24, 2014
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Service Chain Header . . . . . . . . . . . . . . . . . . . . . 5
4.1 Header Format . . . . . . . . . . . . . . . . . . . . . . . 5
4.2 Mandatory Fields . . . . . . . . . . . . . . . . . . . . . . 6
4.3 Optional Metadata Fields . . . . . . . . . . . . . . . . . . 8
4.4 Header Associated Operations . . . . . . . . . . . . . . . . 9
5. SCH Encapsulation . . . . . . . . . . . . . . . . . . . . . . . 10
5.1 SCH in Overlay GRE Encapsulation . . . . . . . . . . . . . . 10
5.2 SCH in MAC Encapsulation . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA and IEEE Considerations . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1 Normative References . . . . . . . . . . . . . . . . . . . 11
8.2 Informative References . . . . . . . . . . . . . . . . . . 12
9. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1 OAM Operation . . . . . . . . . . . . . . . . . . . . . . . 13
9.2 Service Function Selector . . . . . . . . . . . . . . . . . 13
9.3 Target Address . . . . . . . . . . . . . . . . . . . . . . . 13
9.4 OAM Service Function Trace . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Zhang, et al Expires September 25, 2014 [Page 2]
Internet-Draft Service Chain Header March 24, 2014
1. Introduction
Service chaining is a traffic steering technology for applying an
ordered set of network service functions to traffic flows between two
endpoints. Network service functions may include NAT, firewall,
server load balancing, WAN optimization, and others, many of which
can operate up to OSI Layer 7, and run on hardware appliances or
virtual machines.
Service function chaining is an enabling technology for providing
more agile service delivery required by cloud computing and network
functions virtualization. (See [SFC-PS] and [SFC-ARCH] for more
detailed discussions on service chaining.)
In order to support service function chaining, a mechanism is needed
to carry service function chain (SFC) path and optional metadata
information across various SFC entities. Ideally, the mechanism
imposes minimal network overhead, works over various transport
technologies at different OSI layers, and can accommodate future
services. Given the likelihood of innovation in existing and future
service functions and the impossibility of predicting what form every
type of metadata will take, the mechanism should allow for the
flexibility of carrying different types and lengths of metadata for
different usage scenarios, and accommodate the addition of new types
of service metadata. (See [SFC-META] for metadata considerations for
service function chains.)
It is acknowledged that either out-of-band or inband mechanism or a
combination of both may be utilized to transfer metadata in service
function chains. This document describes only an inband mechanism.
This document proposes the use of the Service Chain Header (SCH),
which comprises a fixed-length mandatory portion used for steering
purposes and an optional variable-length TLV (Type-Length-Value)
approach to carry inband metadata between service function chaining
entities.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Terminology
Zhang, et al Expires September 25, 2014 [Page 3]
Internet-Draft Service Chain Header March 24, 2014
Most of the terminologies used in this document are from [SFC-ARCH],
[SFC-FWK] and [SFC-META], and are summarized here for convenience:
Service Function (SF): A network function that provides a value-added
service to packet flows. A service function can act at any OSI
layer. Service functions include: firewall, DPI (Deep Packet
Inspection), NAT, HTTP Header Enrichment function, TCP optimizer,
load-balancer, etc.
SF Chain: An ordered list of Service Function instances. See SF Map.
SF Chain Identifier: Identifies an SF Chain (SF Map Index).
SFC-enabled domain: Denotes a network (or a region thereof) that
implements SFC.
SF Identifier: A unique identifier that unambiguously identifies an
SF within an SFC-enabled domain. SF Identifiers are assigned,
configured and managed by the administrative entity that operates
the SFC-enabled domain. SF identifiers can be structured as
strings, or in other formats. SF Identifiers are not required to
be globally unique nor be exposed to or used by another SF-enabled
domain.
Service Function Forwarder (SFF): Provides service layer forwarding.
An SFF receives frames/packets from an SFC Network Forwarder and
forwards the traffic to the associated SF(s) using information
contained in the SCH.
SFC Network Forwarder (SNF): Forwards traffic flows along the SFPs
they belong to based on the information contained in the SFC
encapsulation.
SF Map: Refers to an ordered list of SF identifiers. Each SF Map is
identified with a unique identifier called SF Map Index. This is
referred to as a service function chain in this document.
SF Locator: An SF Node identifier used to reach the said SF node. A
locator is typically an IP address or a FQDN.
Legacy Node: Refers to any node that is not an SF Node nor an SFC
Boundary Node. This node can be located within an SFC-enabled
domain or outside an SFC-enabled domain.
SF Proxy Node: A Network Element along the data path, to enforce SFC
functions on behalf of legacy SF nodes.
SFC Boundary Node (or Boundary Node): Denotes a node that connects
Zhang, et al Expires September 25, 2014 [Page 4]
Internet-Draft Service Chain Header March 24, 2014
one SFC-enabled domain to a node either located in another SFC-
enabled domain or in a domain that is SFC-unaware.
SFC Egress Node (or Egress Node): Denotes an SFC Boundary Node that
handles traffic which leaves the SFC-enabled domain the Egress
Node belongs to.
SFC Ingress Node (or Ingress Node): Denotes an SFC Boundary Node that
handles the traffic entering the SFC-enabled domain the Ingress
Node belongs to.
SF Node: Denotes any node within an SFC-enabled domain that embeds
one or multiple SFs.
Service Instance (SI): Denotes an instantiation of a service function
on a service node, such as a FW instance. A service function can
have multiple service instances running on the same SF node with
each service instance having its own service profile.
SFC Classifier (or Classifier): An entity that classifies frames or
packets for service chaining according to classification rules
defined in an SFC Policy Table. Frames/packets are then marked
with the corresponding SF Chain Identifier. SFC Classifier can be
embedded in an SFC Boundary (Ingress) Node or SF proxy node in
which case the Classifier will do the encapsulation after getting
the L2/L3 frame/packet from a Legacy SN. The SFC Classifier can
also run on an independent (physical or virtual) platform.
Metadata: Provides contextual information about the data packets
which traverse a service chain. Metadata can be used to convey
contextual information not available at one location in the
network to another location in the network where that information
is not readily available. While primarily intended for consumption
by SF(s), metadata MAY also be interpreted by other SFC entities.
4. Service Chain Header
4.1 Header Format
The Service Chain Header (SCH) consists of a mandatory fixed length
part followed by a number of optional variable length metadata as
shown in Figure 1. The mandatory fields carry "SFC path" information,
which is used to steer the frames or packets through an ordered set
of service function instances along the service function chain. The
optional variable length fields carry application/service/content
related metadata information which can be used by any SFC entities.
The optional fields are formatted as Type-Length-Value structures. If
any field in the header is not in use, the value of that field MUST
Zhang, et al Expires September 25, 2014 [Page 5]
Internet-Draft Service Chain Header March 24, 2014
be set to zero.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |O|R|R|R|R|Metadata Length| Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Identifier | SF Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Metadata TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Service Chain Header
4.2 Mandatory Fields
Ver: Represents the Service Chain Header version. This field is 3
bits long, and the current version is 0.
O bit: Indicates that this frame/packet is an operations and
management (OAM) packet. SF nodes MUST examine the payload and
take appropriate action (i.e. return status information). OAM
message specifics and handling details are outside the scope of
this document.
R bits: Reserved bits for future extensions. These bits MUST be set
to zero on transmit, and ignored on receive.
Metadata length: The total length of all of the optional Metadata
TLVs, in 4 octet units.
Protocol type: The 2-octet IEEE EtherType of the packet or frame
immediately following the entire SCH header [ETYPES].
Path Identifier: Identifies a fully instantiated service function
path. It represents a sequence of network locators, one for each
service function that is to be invoked. Participating SFC entities
MUST use this identifier when selecting the next hop for the
packet or frame. The path identifier can also be used for
diagnostics and trouble-shooting associated with a service chain.
Service Function Index: An index to each service function instance
associated with the service path. The service path index can be
used to handle loop detection, flow reentry into a previous SF
node of the SFC requiring another different service instance
treatment, etc. The first service function instance in the path
is identified with service index 1.
Zhang, et al Expires September 25, 2014 [Page 6]
Internet-Draft Service Chain Header March 24, 2014
Zhang, et al Expires September 25, 2014 [Page 7]
Internet-Draft Service Chain Header March 24, 2014
4.3 Optional Metadata Fields
Optional metadata are added after the fixed part of the SCH. Each
option is of variable length and has a minimum length of four octets.
An optional 3-octet Organizational Unique Identifier (OUI) may be
provided to differentiate multiple private number spaces for the Type
field. If the OUI is not provided, the Type is assumed to be a
registered globally unique type. Any SFC entities MAY add, modify, or
remove metadata TLVs.
The Appendix provides some examples of potential metadata TLV types
and usage for reference.
Figure 2 shows the format of the TLV:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|R|R|R|R|R|R|R| Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | OUI (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: TLV format
I bit: I=1 indicates that the optional OUI word (8-bit Reserved and
24-bit OUI) is present in this TLV. I=0 indicates that the the
optional OUI word is not present.
R bits: Reserved bits for future extensions. These bits MUST be set
to zero on transmit and ignored on receive.
Type: The type of the TLV, interpreted globally or per the OUI if
present. A maximum of 256 types may be expressed within any
particular number space.
Length: The total length of the TLV in 4-octet units. A maximum
length of 1024 octets may be expressed.
OUI: The 24-bit Organizational Unique Identifier [IEEE-OUI], present
only if the I bit is set.
Value: Usage of the the 8-bit value in the first word is purely
optional and may be useful for certain types of metadata, allowing
registered types to fit into one 32-bit word and OUI-based types
Zhang, et al Expires September 25, 2014 [Page 8]
Internet-Draft Service Chain Header March 24, 2014
to fit into two 32-bit words. When the 8-bit value is
insufficient, additional words for the value are added to the end
of the TLV. The existence of optional value words is inferred from
the value of the Length field and the value of the I bit.
4.4 Header Associated Operations
The Service Chain Header is processed by SFC-aware entities. These
entities include but are not limited to the SFC classifiers, SF
nodes, SF forwarding nodes, SFC boundary nodes, and SF proxy nodes.
The SCH can be used by any SFC entities. Its use between the SFF and
SF is optional and in many cases will be implementation dependent.
The typical SFF behavior is simplified due to the presence of the
metadata length field in the fixed portion of the header.
These entities can perform the following operations related to the
SCH:
1. Insertion of the Service Chain Header. This occurs at the start of
a service chain. An SFC classifier determines which frames/packets
are associated with which service chain. The classifier performs
this task by matching the incoming frames/packets against certain
flow descriptors and assigning them to specific chains. The
service classifier MUST then insert appropriate SCH in the
frames/packets of a flow that has been assigned to a service
chain.
2. Removal of the Service Chain Header. This occurs at the end of the
service path. The last Service Network Forwarder (SNF) in the
service path MUST remove the SCH from the frames/packets and then
forward them to their final destination using its existing
transport mechanism. This MUST also be performed by an SF Proxy
Node if it is the last forwarding node.
3. Service Path Selection. The Service Network Forwarder (SNF) uses
the Service Chain Identification information in the SCH to steer
the traffic flow along the SFC path.
4. Service Function Instance Selection. The Service Function
Forwarder (SFF) uses the Service Chain Identification information
in the SCH to locate the service instance and forward the traffic
flow to the service instance. The mapping of the Service Chain
Identification to a service instance can be established through
the management/control plane, which is out of scope of this
document.
5. Service Treatment. The Service Node could use the Service Chain
Identification information as well as service metadata in the SCH
Zhang, et al Expires September 25, 2014 [Page 9]
Internet-Draft Service Chain Header March 24, 2014
to locate the service instance associated with the service chain
and apply appropriate service treatment.
5. SCH Encapsulation
The SFC classifier adds the SCH to the original frame or packet, and
then adds the transport header used to forward the frame/packet
through the service chain.
The SCH is independent of the underlying transport used. It can be
encapsulated inside any transport mechanism. The following examples
illustrate how the SCH can be encapsulated in typical transport
mechanisms.
5.1 SCH in Overlay GRE Encapsulation
The SCH can be encapsulated in a GRE header as follows:
+-----------------------------+
| Outer MAC Header |
+-----------------------------+
| Outer IP Header (proto=47) |
+-----------------------------+
| GRE Header (proto=SCH) |
+-----------------------------+
| SCH (proto=GRE Payload Type)|
+-----------------------------+
| GRE Payload |
+-----------------------------+
Figure 3: SCH Encapsulation in GRE Header
Set GRE Protocol = SCH Ethertype
SCH inserted between the GRE header and GRE Payload
5.2 SCH in MAC Encapsulation
The SCH can be encapsulated in a MAC header as follows:
+-----------------------------+
| MAC Header (etype=SCH) |
+-----------------------------+
| SCH (proto=MAC Payload Type)|
+-----------------------------+
| MAC Payload |
Zhang, et al Expires September 25, 2014 [Page 10]
Internet-Draft Service Chain Header March 24, 2014
+-----------------------------+
Figure 4: SCH Encapsulation in MAC Header
Set MAC Ethertype = SCH Ethertype
SCH inserted between the MAC header and MAC Payload
6. Security Considerations
Although the SCH can be modified or spoofed by an unauthorized party,
various options are available to avoid this.
Existing security protocols RFC 6071 [RFC6071] may be used to encrypt
the content of a packet that includes the SCH. It should be noted
that encryption and decryption of the SCH will impose a performance
penalty. Existing security protocols that provide authenticity and
authorization (e.g., RFC 2119 [RFC6071]) can be used.
If possible, the SCH should be used in a controlled network with
trusted devices, for example, a data center or a Gi-LAN network, thus
reducing the risk of unauthorized header manipulation.
7. IANA and IEEE Considerations
Non-OUI TLV types shall be assigned by IANA.
An EtherType assignment for the SCH will be requested from IEEE.
8. References
8.1 Normative References
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC0781] Su, Z., "Specification of the Internet Protocol (IP)
timestamp option", RFC 781, May 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
Zhang, et al Expires September 25, 2014 [Page 11]
Internet-Draft Service Chain Header March 24, 2014
February 2011.
[ETYPES] The IEEE Registration Authority, "IEEE 802 Numbers", 2012,
<http://www.iana.org/assignments/ieee-802-numbers/ieee-
802-numbers.xml>.
[IEEE-OUI] IEEE Standard 802-2001
8.2 Informative References
[SFC-ARCH] Quinn, P. et al, Service Function Chaining (SFC)
Architecture <https://datatracker.ietf.org/doc/draft-
quinn-sfc-arch/>.
[SFC-FWK] Boucadair, M. et al, Service Function Chaining: Framework &
Architecture, 2014,
<http://datatracker.ietf.org/doc/draft-boucadair-sfc-
framework/>.
[SFC-META] Rijsman, B. and J. Moisand, Metadata Considerations
<http://http://datatracker.ietf.org/doc/draft-rijsman-sfc-
metadata-considerations/>.
[SFC-PS] Quinn, P., Ed. and T. Nadeau, Ed., "Service Function
Chaining Problem Statement", 2014,
<http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-
statement/>.
Zhang, et al Expires September 25, 2014 [Page 12]
Internet-Draft Service Chain Header March 24, 2014
9. Appendix
The Appendix gives some examples of potential metadata TLV types and
usage. It is out of scope of the document to define the list of types
and usage. For exemplary purposes only, the formats assume globally
registered types (i.e., the OUI word is not present).
9.1 OAM Operation
The OAM Operation TLV allows a service function to specify an action
to be taken by a downstream service function as a result of its
service processing.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|R|R|R|R|R|R|R| Type=1 | Length=1 | Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service actions could include the following:
1 = drop packet
2 = redirect flow
3 = mirror flow
4 = terminate connection
9.2 Service Function Selector
The Service Function Identifier TLV allows a service function to
select a specific service function to be used on a downstream service
node.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|R|R|R|R|R|R|R| Type=2 | Length=2 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Function Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9.3 Target Address
The Target Address TLV allows an original destination IP address to
be transported across the service chain to the last service function
which restores that IP address to the destination IP address of the
original packet.
Zhang, et al Expires September 25, 2014 [Page 13]
Internet-Draft Service Chain Header March 24, 2014
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|R|R|R|R|R|R|R| Type=3 | Length=3 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Function Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9.4 OAM Service Function Trace
The OAM Service Function List TLV supports OAM functionality and is
used to obtain a list of service functions that have been traversed
by the packet. Each service function adds its service function
identifier to this list if the OAM Operation TLV indicates an SF
Identifier.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|R|R|R|R|R|R|R| Type=4 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Function Identifiers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authors' Addresses
Hong (Cathy) Zhang
Huawei US R&D
EMail: cathy.h.zhang@huawei.com
Louis Fourie
Huawei US R&D
EMail: louis.fourie@huawei.com
Ron Parker
Affirmed Networks
EMail: ron_parker@affirmednetworks.com
Zhang, et al Expires September 25, 2014 [Page 14]
Internet-Draft Service Chain Header March 24, 2014
Myo Zarny
Goldman Sachs
EMail: myo.zarny@gs.com
Zhang, et al Expires September 25, 2014 [Page 15]