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]