Internet DRAFT - draft-cao-nsc-rtg-update
draft-cao-nsc-rtg-update
Internet Engineering Task Force Z. Cao
Internet-Draft China Mobile
Intended status: Experimental October 21, 2013
Expires: April 24, 2014
Routing Update Mechanism for Network Service Chaining
draft-cao-nsc-rtg-update-00
Abstract
This document proposes a mechanism of routing the packets through a
series of (virtual) service functions. The mechanism uses the
existing IPv6 Mobility Header for routing advertisements, updates and
acknowledgements. Comparison with existing service chaining
mechanisms is to be analyzed.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 24, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Cao Expires April 24, 2014 [Page 1]
Internet-Draft Mobility Header for NSC October 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Solution Highlighted . . . . . . . . . . . . . . . . . . . . 3
5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
[Quoted from the BOF page] Service function chaining is a broad term
used to describe a common model for delivering multiple service
functions in a specific order. Service function chaining de-couples
service delivery from the underlying network topology and creates a
dynamic services plane that addresses the requirements of cloud and
virtual application delivery. Packets and/or flows that require
services to be applied are classified and redirected to the
appropriate service functions. Additionally, context can be shared
between the network and the services. Service function chaining has
also been discussed in other forums e.g. ETSI and 3GPP, and the ETSI
NFV group is discussing service function chaining as part of network
function virtualization.
The central problem of service chaining is how to routing the packets
with fixed source and destination IP address to a chain of different
network service functions such as NAT, Firewall, Charging GW, DPI and
Policy servers. Some expressed the problem using the saying "Hey,
this packet lacks context".
Although the IETF is still discussing necessity to solving the
network service chaining problem, many solutions already existed on
the operator and service provider's 'table'. For example, service
header solutions[I-D.quinn-nsh] and the solution of using 'Openflow'
controller and protocol for different scenarios.
This document proposes a mechanism of using existing IPv6 Mobility
Header [RFC3775] to solve the problem. The mobility header is used
for routing advertisements, updates and acknowledgements.
2. Requirements Language
Cao Expires April 24, 2014 [Page 2]
Internet-Draft Mobility Header for NSC October 2013
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
NF (Network Function): A functional building block within an
operator's network infrastructure, which has well-defined external
interfaces and a well-defined functional behaviour. Note that the
totality of all network functions constitutes the entire network and
services infrastructure of an operator/service provider. In
practical terms, a Network Function is today often a network node or
physical appliance. [Quoted from ETSI NFV]
Virtualised Network Function (VNF): An implementation of an
executable software program that constitutes the whole or a part of
an NF that can be deployed on a virtualisation infrastructure.
Service Classifier: A component that performs traffic classification.
Classification is the precursor to the start of a service chaining
path. Meta-data could assist traffic classification. Service
classification is different from DPI component where only service
related information in packets is retrieved and classified.
Mobility Header: referred to IPv6 Mobility Header defined in
[RFC3775].
4. Solution Highlighted
This section describes the solution using routing update messages to
chain different NFs.
The flow chart of a successful routing update is depicted below
Figure 2.
As depicted in the architecture document [I-D.quinn-nsc-arch] ,the
packets will be classified by a 'service classifier' before hitting
the NFs. So the Service Classifier can apply the Mobility Header in
the packet with the service type information (to be extended). The
NFs will determine the routing and encapsulation sequences.
The chaining NFs will use the mobility messages defined in [RFC3775]
and will be specified in this document to establish the service
chains.
+-------+
+----------+|control|+----------+
| |plane | |
Cao Expires April 24, 2014 [Page 3]
Internet-Draft Mobility Header for NSC October 2013
| +---+---+ |
| | |
v v v
,---. ,---. ,---.
+----------+ / \+------->/ \+-------->/ \
|classifier|+--->( NF_1 ) ( NF_2 ) ( NF_3 )
+----------+ \ /<-------+\ /<--------+\ /
`---' `---' `---'
Figure 1: Network Function Chaining Architecture
The chaining NFs will use the mobility messages to be specified in
this document to establish the service chains.
First, the chaining can be established with a sequence of point to
point encapsulations, NF1 encapsulates the original packets to NF2,
and NF2 first decapsulates and then re-encapsulate with NF3 as the
tunnel end-points, so finally the packet with be processed by
different NFs in a pre-defined sequences. The sequence will be
defined and pre-loaded to the NFs by the controller plane component
in the architecture figure above.
The following figure Figure 2 shows the way to establish the chain.
The NF2 will send the 'Binding Update' message containing the service
type mobility option to NF1 on IP_f1. The NF1 will check the
validity of the message and determine the encapsulation end-points
for this certain service type. In a successful case, NF1 will first
add a routing entry for this type of service and then acknowledge NF2
with a 'Binding ACK' message.
After the above exchange, the control plane i.e., the encapsulation
logic has been established. When data with the service type arrives
at NF1, NF1 will check the information in the mobility header and
then encapsulated into the tunnel. NF2 receives the message and
decapsulate it and process, and it will determine if further
processing with other NFs is needed.
+----------+ +----------+
| NF1/IP_f1| | NF2/IP_f2|
+----------+ +----------+
| Binding Update |
|<----------------------------------------------|
| Binding ACK |
|---------------------------------------------->|
|Tunnel |Tunnel
|established |established
| |
Received pkt with TOS in Mobility Header |
Cao Expires April 24, 2014 [Page 4]
Internet-Draft Mobility Header for NSC October 2013
----->| |
|<--------------------------------------------->|
| Encapsulated PKT{IP_f1|IP_f2|IP_s|IP_d|...} |
|<--------------------------------------------->|
| |
Figure 2: Routing Update Mechanism for Network Service Chaining
5. Message Formats
This section reviews what extensions to Mobility Headers are needed.
The Mobility Header is identified by a Next Header value of 135 in
the immediately preceding header, and has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto | Header Len | MH Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. Message Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Binding Update uses the MH Type value 5. When this value is
indicated in the MH Type field, the format of the Message Data field
in the Mobility Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Mobility options .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There is need of a new Mobility Option containing TOS type
information. The TOS type information should be aligned with the
Service Classifier who set it in the Mobility Header.
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
Cao Expires April 24, 2014 [Page 5]
Internet-Draft Mobility Header for NSC October 2013
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TOS Option Type| Option Length | Option Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6. IANA Considerations
To be specified.
7. Security Considerations
TBD.
8. References
8.1. Normative References
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
8.2. Informative References
[I-D.quinn-nsc-arch]
Quinn, P., Guichard, J., Surendra, S., and C. Pignataro,
"Service Function Chaining (SFC) Architecture", draft-
quinn-nsc-arch-00 (work in progress), September 2013.
[I-D.quinn-nsh]
Quinn, P., Fernando, R., Guichard, J., Surendra, S.,
Agarwal, P., Manur, R., Chauhan, A., Smith, M., Yadav, N.,
McConnell, B., and C. Wright, "Network Service Header",
draft-quinn-nsh-01 (work in progress), July 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
Cao Expires April 24, 2014 [Page 6]
Internet-Draft Mobility Header for NSC October 2013
Author's Address
Zhen Cao
China Mobile
Xuanwumenxi Ave. No. 32
Beijing 100053
China
Email: zehn.cao@gmail.com, caozhen@chinamobile.com
Cao Expires April 24, 2014 [Page 7]