[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

SFC WG                                                             T. Ao
Internet-Draft                                           ZTE Corporation
Intended status: Informational                                    W. Wei
Expires: April 23, 2019                                         Y. Zheng
                                                               ZTE Corp.
                                                        October 20, 2018


                      SFC transport considertation
                       draft-ao-sfc-transport-00

Abstract

   A Network Service Header(NSH) is imposed encapsulates a packet or a
   frame for Service Function Chaining.  The resulting packet, in turn,
   is encapsulate according to transport layer.  The NSH contains a
   Service Path Identifier (SPI) and a Service Index (SI).  The SPI is,
   as per its name, an identifier.  The SPI alone cannot be used to
   forward packets along a service path.  Rather, the SPI provides a
   level of indirection between the service path / topology and the
   network transport encapsulation.  For different transport
   encapsulations, this document provides the format information with
   transport and NSH, and gives operational constraints that transport
   technologies, used by NSH need to meet.

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 https://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 23, 2019.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Ao, et al.               Expires April 23, 2019                 [Page 1]


Internet-Draft         SFC transport consideration          October 2018


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   4
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   3.  Ethernet as transport . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Format in encapsulation . . . . . . . . . . . . . . . . .   4
     3.2.  Operation . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  VXLAN-GPE as transport  . . . . . . . . . . . . . . . . . . .   6
     4.1.  Format in encapsulation . . . . . . . . . . . . . . . . .   6
     4.2.  Operation . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  GRE as transport  . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Format in encapsulation . . . . . . . . . . . . . . . . .   7
     5.2.  Operation . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  GENEVE as transport . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Format in encapsulation . . . . . . . . . . . . . . . . .   8
     6.2.  Operation . . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     10.2.  Informational References . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   For SFC using NSH, NSH is imposed on original packets/frames.  NSH
   hearder format is defined in [RFC8300] as Figure 1.  NSH is transport
   encapsulation agnostic, and SFC packet can't be forwarded or
   transmitted along without the transport layer support.  So how does
   the different transport technologies bear SFC service traffic is what
   is discussed in this document.







Ao, et al.               Expires April 23, 2019                 [Page 2]


Internet-Draft         SFC transport consideration          October 2018


                                 +------------------------------+
                             |    Transport Encapsulation   |
                             +------------------------------+
                             | Network Service Header (NSH) |
                             +------------------------------+
                             |    Original Packet / Frame   |
                             +------------------------------+
                                                          Figure 1

              Figure 1: Network Service Header Encapsulation

   The NSH is composed of a 4-byte Base Header, a 4-byte Service Path
   Header, and optional Context Headers, as shown in Figure 2.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Base Header                                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Service Path Header                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                Context Header(s)                              ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           Figure 2

                     Figure 2: Network Service Header

   In the Base Header part, a Next Protocol field is provided to
   indicate the protocol type of the payload.  The value definition is:

   o  0x1: IPv4

   o  0x2: IPv6

   o  0x3: Ethernet

   o  0x4: NSH

   o  0x5: MPLS

   o  0xFE: Experiment 1

   o  0xFF: Experiment 2

   This document describes SFC packet over different transport networks,
   and defines the format for NSH with these different transport



Ao, et al.               Expires April 23, 2019                 [Page 3]


Internet-Draft         SFC transport consideration          October 2018


   protocol.  For some situations, some operational constraints also
   described.

2.  Conventions used in this document

2.1.  Terminology

   SFC(Service Function Chain): An ordered set of some abstract SFs.

   SFF: Service Function Forwarder

   SF: Service Function

   NVE: Network Virtualization Edge

   VXLAN-GPE: VXLAN Generic Protocol Extension

   GENEVE: Generic Network Virtualization Encapsulation

   GRE: Generic Routing Encapsulation

2.2.  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.

3.  Ethernet as transport

3.1.  Format in encapsulation

   In an Ethernet network, Ethernet is as transport for SFC traffic.
   The format for Ethernet to tranport SFC packet should be as Figure 3.
















Ao, et al.               Expires April 23, 2019                 [Page 4]


Internet-Draft         SFC transport consideration          October 2018


     +-----------------------------+--------------------------------+---------------------------+
     | L2 Header, EtherType=0x894F | NSH Header, Next Protocol=0x01 |  Original IPv4 Packet     |
     +-----------------------------+--------------------------------+---------------------------+
      Ethernet+ NSH IPv4 packet

     +-----------------------------+--------------------------------+---------------------------+
         | L2 Header, EtherType=0x894F | NSH Header, Next Protocol=0x03 |  Original L2 frame        |
         +-----------------------------+--------------------------------+---------------------------+
      Ethernet+ NSH L2 frame
                                   Figure 3 NSH in Ethernet

                         Figure 3: NSH in Ethernet

3.2.  Operation

   1.The Classifier classifies the original packets according to its
   policies and attach the NSH header.  If the network transport is
   Ethernet, before the Classifier forwards the packet, it adds a L2
   Header as the outer header.  In the outer L2 header, the source MAC
   address is the MAC address of the Classifier, and the destination MAC
   address is the MAC address of the first SFF.

   For the VLAN ID in the L2 header, there should be a policy for impose
   a VLAN ID.  If the original packet is IP Packet, the VLAN ID relies
   on the Service Function Path assigned to the packet which virtual
   network it belongs.

   2.The SFF receives SFC packet from a network interface, checks the
   SPI and SI in the NSH-to-SF Mapping table, per [RFC8300], to get the
   locator of SF attached to it, that is MAC address if the transport is
   Ethernet.  SFF modifies the L2 Header to be the destination MAC
   addess is the SF MAC address, and the source MAC address is the MAC
   address of the SFF, and then forwards the SFC packet to the SF
   attached to this SFF.  After the processing, the SF will decrement SI
   in the NSH by a value of 1, and will swap the source MAC address with
   the destination MAC address of the outer L2 Header, and then the SFC
   packet is forwarded back to the SFF.  Once the SFF receives the SFC
   packet from SF interface, it will check the SFI and SI in the NSH-to-
   SF Mapping table again to get the locator of next SFF, that is MAC
   address of the next SFF if the transport is Ethernet.  SFF should
   modify the L2 Header again to be the the destination MAC address is
   the next SFF address, and the source MAC address is the MAC address
   of the SFF.

   3.When the last SFF receive the SFC packet from the SF attaching to
   it, it will check the SPI and SI in the NSH-to-SF Mapping table,
   finding it's the end of the Service Function Path, so it should strip




Ao, et al.               Expires April 23, 2019                 [Page 5]


Internet-Draft         SFC transport consideration          October 2018


   the outer L2 Header and NSH Header before it send out the original
   packet .

4.  VXLAN-GPE as transport

4.1.  Format in encapsulation

   In an overlay network, VXLAN-GPE is as transport for SFC traffic.
   The format for VXLAN-GPE to transport SFC packet should be as
   Figure 4.  Here assuming the overlay networks are built on Ethernet.


     +----------+------------------------+---------------------+--------------+---------------------+
     |L2 header | IP + UDP dst port=4790 |VXLAN-gpe NP=0x4(NSH)|NSH, NP=0x1   |original IPv4 packet |
     +----------+------------------------+---------------------+--------------+---------------------+
     VXLAN-GPE+ NSH IPv4 packet

     +----------+------------------------+---------------------+--------------+---------------------+
     |L2 header | IP + UDP dst port=4790 |VXLAN-gpe NP=0x4(NSH)|NSH,NP=0x3    |original L2 frame    |
     +----------+------------------------+---------------------+--------------+---------------------+
     VXLAN-GPE+ NSH L2 frame
                                           Figure 4  NSH in VXLAN-GPE


                        Figure 4: NSH in Vxlan-GPE

4.2.  Operation

   1.The Classifier classifies the original packets according to the
   classify its policies and attaches the NSH header.  If the network
   transport is VXLAN-GPE, before the Classifier forward the packet, it
   should add a VXLAN-GPE header first, and then UDP header and IP
   header.  UDP destination port should be 4790 which means the traffic
   should send to NVE, which has been specified in
   [I-D.ietf-nvo3-vxlan-gpe].  The destination IP address should be the
   IP address of the NVE that the first SFF located.  For the VNID in
   the VXLAN-GPE header, there should be a policy for impose a VNID.  If
   the original frame has VLAN ID, there would be a mapping between VLAN
   ID and VNID.

   2.The SFF receives SFC packet from network interface, remove the
   outer header and checks the SPI and SI in the NSH-to-SF Mapping table
   in [RFC8300] to get the locator of SF attaching to it.  If the
   transport between the SFF and the SF attaching to the SFF is
   Ethernet, the locator of SF in the NSH-to-SF Mapping table should be
   MAC address.  At this time, the SFC packet format from SFF to SF is
   as the Figure 3 shows.  So the destination MAC address of the outer
   L2 header should be SF MAC address, and the source MAC address of the



Ao, et al.               Expires April 23, 2019                 [Page 6]


Internet-Draft         SFC transport consideration          October 2018


   outer L2 header should be MAC address of the SFF.  After the process,
   the SF will decrement SI in the NSH by a value of 1, and exchange the
   source MAC address the and destination MAC address of the outer L2
   Header, and then the SFC packet is forwarded back to the SFF.  Once
   the SFF receive the SFC packet from SF interface, it will check the
   SFI and SI in the NSH-to-SF Mapping table again to get the locator of
   next SFF, that is MAC address of the next SFF if the transport is
   Ethernet.  SFF should modify the L2 Header again to be the
   destination MAC address is the next SFF address, and the source MAC
   address is the MAC address of the SFF.

   3.When the last SFF receive the SFC packet from the SF attaching to
   it, it will check the SPI and SI in the NSH-to-SF Mapping table,
   finding it's the end of the Service Function Path, so it should strip
   the outer L2 Header and NSH Header before it send out the original
   packet .

5.  GRE as transport

5.1.  Format in encapsulation

   In an overlay network, GRE is as tranport for SFC traffic.  The
   format for GRE to tranport SFC packet should be as Figure 5.  Here
   assuming the overlay networks are built on Ethernet.

     +----------+------------------------+-------------------+--------------+----------------+
     |L2 header | IP header, Proto=47    |GRE PT=NSH         |NSH, NP=0x1   |original packet |
     +----------+------------------------+-------------------+--------------+----------------+
     GRE+ NSH IPv4 packet

     +----------+------------------------+-------------------+---------------+---------------+
     |L2 header | IP header, Proto=47    |GRE PT=NSH         |NSH,NP=0x3     |original frame |
     +----------+------------------------+-------------------+---------------+---------------+
     GRE+ NSH L2 frame
                                           Figure 5


                           Figure 5: NSH in GRE

5.2.  Operation

   To support the encapsulation, a new value for Protocol Type in GRE is
   required.

   Similar with VXLAN-GPE as transport.  Will add later.






Ao, et al.               Expires April 23, 2019                 [Page 7]


Internet-Draft         SFC transport consideration          October 2018


6.  GENEVE as transport

6.1.  Format in encapsulation

   In an overlay network, GENEVE is as STANDARD transport technology.
   GENEVE also can be used as transport for SFC traffic.  The format for
   GENEVE to tranport SFC packet should be as Figure 6.  Here assuming
   the overlay networks are built on Ethernet.

     +----------+------------------------+-----------------------+--------------+----------------+
     |L2 header | IP + UDP dst port=6081 |GENEVE PT=NSH          |NSH, NP=0x1   |original packet |
     +----------+------------------------+-----------------------+--------------+----------------+
     GRE+ NSH IPv4 packet

     +----------+------------------------+----------------------+---------------+----------------+
     |L2 header | IP + UDP dst port=6081 |GENEVE PT=NSH         |NSH,NP=0x3     |original frame  |
     +----------+------------------------+----------------------+---------------+----------------+
     GRE+ NSH L2 frame
                                           Figure 6


                          Figure 6: NSH in GENEVE

6.2.  Operation

   To support the encapsulation, a new value for Protocol Type in GEVENE
   is required.

   Similar with operation in VXLAN-GPE transport.  Details will be added
   later.

7.  Security Considerations

   TBD.

8.  IANA Considerations

   TBD.

9.  Acknowledgements

   TBD.

10.  References







Ao, et al.               Expires April 23, 2019                 [Page 8]


Internet-Draft         SFC transport consideration          October 2018


10.1.  Normative References

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

   [I-D.ietf-nvo3-vxlan-gpe]
              Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
              Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work
              in progress), April 2018.

   [RFC1701]  Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
              Routing Encapsulation (GRE)", RFC 1701,
              DOI 10.17487/RFC1701, October 1994,
              <https://www.rfc-editor.org/info/rfc1701>.

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

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

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

   [RFC8300]  Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
              "Network Service Header (NSH)", RFC 8300,
              DOI 10.17487/RFC8300, January 2018,
              <https://www.rfc-editor.org/info/rfc8300>.

10.2.  Informational References

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

Authors' Addresses







Ao, et al.               Expires April 23, 2019                 [Page 9]


Internet-Draft         SFC transport consideration          October 2018


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

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


   Wei Wei
   ZTE Corp.
   No.50, Ruanjian Avenue
   Nanjing
   China

   Email: wei.wei@zte.com.cn


   Yan Zheng
   ZTE Corp.
   No.50, Ruanjian Avenue
   Nanjing
   China

   Email: zheng.yan@zte.com.cn

























Ao, et al.               Expires April 23, 2019                [Page 10]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/