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]