Internet DRAFT - draft-ao-sfc-overlay

draft-ao-sfc-overlay







SFC WG                                                             T. Ao
Internet-Draft                                           ZTE Corporation
Intended status: Standards Track                               G. Mirsky
Expires: January 3, 2018                                       ZTE Corp.
                                                            July 2, 2017


              Interworking SFC network and Overlay network
                        draft-ao-sfc-overlay-02

Abstract

   Service Function Chain (SFC) network presents a distinct network
   layer.  As such, it is carried over by an underlay network.  The
   document reviews two interworking scenarios between the SFC domain
   and its underlay network - co-located and stand-alone.  The document
   also defines necessary interworking between stand-alone Network
   Virtual Edge and Service Forwarding Function entities to ensure
   proper handling of SFC traffic by the underlay network.

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 January 3, 2018.

Copyright Notice

   Copyright (c) 2017 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



Ao & Mirsky              Expires January 3, 2018                [Page 1]

Internet-Draft                 SFC overlay                     July 2017


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   4.  Interworking Action . . . . . . . . . . . . . . . . . . . . .   3
     4.1.  Co-located NVE-SFF  . . . . . . . . . . . . . . . . . . .   5
     4.2.  Stand-alone NVE-SFF . . . . . . . . . . . . . . . . . . .   5
       4.2.1.  Classifier-based Action . . . . . . . . . . . . . . .   5
       4.2.2.  SFF-based Action  . . . . . . . . . . . . . . . . . .   5
       4.2.3.  NVE-based Action  . . . . . . . . . . . . . . . . . .   6
   5.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Service Function Chaining (SFC) is a technique for prescribing
   differentiated traffic forwarding policies within the SFC domain.
   SFC architecture has been defined in [RFC7665].

   SFC traffic is transferred in overlay network, which is described in
   SFC architecture document [RFC7665].  In an underlay network, Network
   Virtualization Edge (NVE) maps the traffic to a tunnel according to
   the inner destination address of the particular flow, then
   encapsulates the packet into outer layer, specific to the underlay
   network.  In this document, we assume that the NVEs in overlay
   network have already obtained the mapping information between NVE and
   Service Functions (SFs), as described in NVO3 network framework
   [RFC7365].

   But the destination address of SFC traffic is the final destination
   of the traffic, not the next hop of the SFC, so that NVE will not
   tunnel the traffic to the next SF, but encapsulate the SFC traffic
   with the NVE address connected to the destination station.  So it's
   important to coordinate SFC domain and corresponding underlay
   network.  Underlay network edge device NVE needs to know how to
   forward SFC traffic, i.e., NVE should only encapsulate the SFC
   traffic into the tunnel to the next hop of the SFC.  This document




Ao & Mirsky              Expires January 3, 2018                [Page 2]

Internet-Draft                 SFC overlay                     July 2017


   analyzes how SFC domain can be coordinated with the underlay network
   to ensure that SFC traffic can be forwarded properly.

2.  Terminology

   The document uses the terminology in defined in [RFC7665] and
   [RFC7365].

   NVE: Network Virtualization Edge

   NSH: Network Service Header

   SFC: Service Function Chain

   SFF: Service Function Forwarder

   SF: Service Function

   SFP: Service Function Path

   SFP ID: SFP Identifier

3.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

4.  Interworking Action




















Ao & Mirsky              Expires January 3, 2018                [Page 3]

Internet-Draft                 SFC overlay                     July 2017


        +--------------------------------------------------------------+
        |                                                              |
        |                          Transport Network                   |
        |                                                              |
        |  +---------+    +---------+     +---------+     +---------+  |
        +--|  NVE4   |----|  NVE1   +-----+  NVE2   +-----+  NVE3   +--+
           +---+-----+    +----+----+     +----+----+     +----+----+
               | |/ \          | |/ \          | |/ \            | |
              \ /| |          \ /| |          \ /| |            \ /|
          +-----+----+ ===> +----+----+ ===> +----+----+ ===> +----+---+
          |Classifier+------+  SFF1   +------+  SFF2   +------+    D   |
          +----------+      +----+----+      +----+----+      +----+---+
                                 |                 |
                            +----+----+ ===> +----+----+
                            +   SF1   +------+   SF2   +
                            +----+----+      +----+----+
                            ==> - path through overlay network
                            --> - path through underlay network

                    Figure 1: SFC and NVO Interworking

   Figure 1 reflects how SFC traffic is transported by the underlay
   network through Classifier, then to SF1 and SF2 to the destination at
   D.  Devices NVE1 through NVE4 are to encapsulate the SFC packets into
   the underlay header, e.g., GENEVE [I-D.ietf-nvo3-geneve].  Once
   packet addressed to the node D has been processed by Classifier it is
   directed to the Service Function Path (SFP) following processing
   takes place:

      NVE4 encapsulates SFC packet and transports it over underlay
      tunnel to NVE1;

      NVE1 decapsulates the SFC packet and passes SFC packet to SFF1;

      after being processed by SF1, SFC packet will be encapsulated by
      NVE1 to be transported over the tunnel to NVE2;

      consequently, NVE2 decapsulates the SFC packet and passes it to
      SFF2;

      after the packet processed by SF2, SFF2 terminates SFP and passes
      user packet to NVE2;

      NVE3, in turn, encapsulates the user payload packet once again and
      sends over underlay tunnel to NVE3;

      NVE3 is expected to decapsulate and pass the user payload to the
      node D.



Ao & Mirsky              Expires January 3, 2018                [Page 4]

Internet-Draft                 SFC overlay                     July 2017


   In order for NVEs to transport the SFC traffic over the underlay
   network through the right tunnel each NVE needs to know what's the
   next hop of the SFC traffic.  In the example presented in Figure 1
   NVE1 needs to know that the traffic should be forwarded to SFF2 which
   is the next hop of the SFC packet in this SFP.  As we know, the SFC
   traffic from Classifier has the destination address of D.  So here is
   a question, if the underlay network and SFC domain are independent,
   NVE1 may tunnel the traffic to NVE3 according to the destination of
   the user packet, which is D in this scenario, and then NVE3 will
   forward the traffic to D, which is a wrong path for the SFC, as it
   will miss the processing by the SF2.  So there must be a way to
   coordinate between overlay network and SFC domain, to make sure that
   the transport path in the underlay network is correct.

4.1.  Co-located NVE-SFF

   When NVE and SFF nodes are co-located coordination between them can
   be achieved through well-defined Application Programming Interface
   (API).  Control plane or SDN controller may signal to NVE and SFF
   that SFF should notify the NVE what the next hop is, and NVE should
   encapsulate the traffic to the next hop NVE according to the address
   of the next hop once it finds that the next protocol is Network
   Service Header (NSH).

4.2.  Stand-alone NVE-SFF

   In this scenario, NVE and SFF are physically separate.  Hence the
   coordination between NVE and SFF should be considered.  Two possible
   solutions are presented, one is from data plane aspect, and another
   is from control plane aspect.

4.2.1.  Classifier-based Action

   Classifier receives traffic from the source device and classifies the
   traffic, then encapsulates into NSH.  When the Classifier forwards
   the packet to SFF1 according to SFP ID in the SFC header, it should
   identify the next hop of the SFC (SF1 for example), and before it
   forwards the traffic to NVE4, the Classifier should change the
   destination of the packet to be the next hop (SF1) and store the
   actual destination address in the SFC header as a metadata.

4.2.2.  SFF-based Action

   Once SFF receives SFC packet from SF, before it forwards the SFC
   traffic to NVE that the SFF is connected to, the SFF should find the
   next hop with the SFP ID in the SFC header of the packet, then
   replace the destination address to next hop, and store the actual
   destination address in the metadata of the SFC header.



Ao & Mirsky              Expires January 3, 2018                [Page 5]

Internet-Draft                 SFC overlay                     July 2017


   Once SFF receives SFC traffic from NVE, before it forwards the SFC
   packet to SF according to SFPID, the SFF should restore the
   destination address back to the actual address that is stored in the
   metadata of the SFC header.

   The last SFF receives the SFC packet from SF, and finds that it is
   the last hop of the SFC, and the next hop is the actual destination
   address in the metadata, so it just restores the destination address
   to the actual destination address.

4.2.3.  NVE-based Action

   NVE receives SFC packet from the Classifier and encapsulates it with
   appropriate underlay network encapsulation, e.g.,GENEVE Header,
   according to the destination address of the next hop.  According to
   the outer address header, the traffic is transmitted to the next NVE
   where it is decapsulated so that it can be forwarded to the
   corresponding SF.  The NVE's action is the same as described in
   [RFC7365]

5.  Conclusions

   As described above, for stand-alone deployment of SFC-NVE, SFF MUST
   use destination of the next SFF in SFP when forwarding SFC packet to
   NVE, SHOULD NOT use the destination address of the original user
   packet.

6.  Security Considerations

   To be added later

7.  IANA Considerations

   TBD

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <http://www.rfc-editor.org/info/rfc8174>.




Ao & Mirsky              Expires January 3, 2018                [Page 6]

Internet-Draft                 SFC overlay                     July 2017


8.2.  Informative References

   [I-D.ietf-nvo3-geneve]
              Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
              Network Virtualization Encapsulation", draft-ietf-
              nvo3-geneve-04 (work in progress), March 2017.

   [RFC7365]  Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
              Rekhter, "Framework for Data Center (DC) Network
              Virtualization", RFC 7365, DOI 10.17487/RFC7365, October
              2014, <http://www.rfc-editor.org/info/rfc7365>.

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <http://www.rfc-editor.org/info/rfc7665>.

Authors' Addresses

   Ting Ao
   ZTE Corporation
   No.889, BiBo Road
   Shanghai  201203
   China

   Phone: +86 21 68897642
   Email: ao.ting@zte.com.cn


   Greg Mirsky
   ZTE Corp.
   1900 McCarthy Blvd. #205
   Milpitas, CA  95035
   USA

   Email: gregimirsky@gmail.com















Ao & Mirsky              Expires January 3, 2018                [Page 7]