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

Versions: 00 01 02

SFC WG                                                             T. Ao
Internet-Draft                                           ZTE Corporation
Intended status: Standards Track                               G. Mirsky
Expires: August 31, 2018                                       ZTE Corp.
                                                                 Z. Chen
                                                           China Telecom
                                                       February 27, 2018


                      SFC OAM for path consistency
                  draft-ao-sfc-oam-path-consistency-02

Abstract

   Service Function Chain (SFC) defines an ordered set of service
   functions (SFs) to be applied to packets and/or frames and/or flows
   selected as a result of classification.  SFC Operation,
   Administration and Maintenance can monitor the continuity of the SFC,
   i.e., that all elements of the SFC are reachable to each other in the
   downstream direction.  But SFC OAM must support verification that the
   order of traversing these SFs corresponds to the state defined by the
   SFC control plane or orchestrator, the metric referred in this
   document as the path consistency of the SFC.  This document defines a
   new SFC OAM method to support SFC consistency, i.e. verification that
   all elements of the given SFC are being traversed in the expected
   order.

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 August 31, 2018.








Ao, et al.               Expires August 31, 2018                [Page 1]


Internet-Draft        SFC OAM for path consistency         February 2018


Copyright Notice

   Copyright (c) 2018 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
   (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 . . . . . . . . . . . . . .   3
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   3.  Consistency OAM: Theory of Operation  . . . . . . . . . . . .   3
     3.1.  COAM packet . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  SF information Sub-TLV  . . . . . . . . . . . . . . . . .   4
     3.3.  SF information Sub-TLV construction . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  COAM Message Types  . . . . . . . . . . . . . . . . . . .   6
     5.2.  SFF Information Record TLV Type . . . . . . . . . . . . .   7
     5.3.  SF Information Sub-TLV Type . . . . . . . . . . . . . . .   7
     5.4.  SF Identifier Types . . . . . . . . . . . . . . . . . . .   7
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informational References  . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Service Function Chain (SFC) is a chain with a series of ordered
   Service Functions (SFs).  Service Function Path (SFP) is a path of a
   SFC.  SFC is described in detail in the SFC architecture document
   [RFC7665].  The SFs in the SFC are ordered and only when traffic is
   processed by one SF then it should be processed by the next SF,
   otherwise errors may occur.  Sometimes, a SF needs to use the
   metadata from its upstream SF process.  That's why it's very
   important for the operator to make sure that the order of traversing
   the SFs is exactly as defined by the control plane or the



Ao, et al.               Expires August 31, 2018                [Page 2]


Internet-Draft        SFC OAM for path consistency         February 2018


   orchestrator.  This document refers to the correspondence between the
   state of control plane and the SFP itself as the SFP consistency.

   This document defines the method to check the path consistency of the
   SFP.  It is an extension of the SFC Echo-request/Echo-reply specified
   in the [I-D.wang-sfc-multi-layer-oam].

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

   OAM: Operation, Administration and Maintenance

   SFP: Service Function Path

   COAM(Consistency OAM): OAM that can be used to check path
   consistency.

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.  Consistency OAM: Theory of Operation

   Consistency OAM uses two functions: COAM Request and COAM Reply.  The
   SFF, that is ingress of the SFP, transmits COAM Request packet.
   Every intermediate SFF that receives the COAM Request MUST perform
   the following actions:

      collect information of traversed by the COAM Request packet SFs
      and send it to the ingress SFF as COAM Reply packet over IP
      network [I-D.wang-sfc-multi-layer-oam];

      forward the COAM Request to next downstream SFF if the one exists.

   As result, the ingress SFF collects information about all traversed
   SFFs and SFs, information of the actual path the COAM packet has
   traveled, so that we can verify the path consistency of the SFC.  The



Ao, et al.               Expires August 31, 2018                [Page 3]


Internet-Draft        SFC OAM for path consistency         February 2018


   mechanism for the SFP consistency verification is outside the scope
   of this document.

3.1.  COAM packet

   Consistency OAM introduces two new types of messages to the SFC Echo
   request/reply operation [I-D.wang-sfc-multi-layer-oam] with the
   following values Section 5.1:

   o  TBA1 - COAM Request

   o  TBA2 - COAM Reply

   An SFF, upon receiving the Consistency OAM Request, MUST include the
   corresponding SFs information, Section 3.2, into the Value field of
   the COAM Reply packet.

   The COAM packet is displayed in Figure 1.


      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Message Type  |   Reply mode  |  Return Code  | Return S.code |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Sender's Handle                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Sequence Number                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Type             |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                             Value                             ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 1: COAM Packet Header

3.2.  SF information Sub-TLV

   Every SFF receiving COAM Request packet MUST include the SF
   characteristic data into the COAM Reply packet.  The per SF data
   included in COAM Reply packet as SF Information sub-TLV that is
   displayed in Figure 2.

   After the COAM traversed the SFP, all the information of the SFs on
   the SFP are collected in the TLVs with COAM Reply.







Ao, et al.               Expires August 31, 2018                [Page 4]


Internet-Draft        SFC OAM for path consistency         February 2018


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     SF sub-TLV Type           |          Length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Service Path Identifier(SPI)            | Service Index |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       SF Type                 |   Reserved    |   SF ID Type  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          SF Identifiers                       |
       ~                                                               ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 2: Service Function information sub-TLV

   Service Path Identifier(SPI): The identifier of SFP to which all the
   SFs in this TLV belong.

   Service Index: indicates the SF's position on the SFP.

   SF sub-TLV Type: is two octets long field.  It indicates that the TLV
   is a SF TLV which contains the information of one SF.

   Length: is two octets long field.  The value of the field is the
   length of the data following the Length field counted in octets.

   SF Type: is two octets long field.  It is defined in
   [I-D.ietf-bess-nsh-bgp-control-plane] and indicates the type of SF,
   e.g., Firewall, Deep Packet Inspection, WAN optimization controller,
   etc.

   Reserved: For future use.  MUST be zeroed on transmission and MUST be
   ignored on receipt.

   SF ID Type: is one octet long field with values defined as
   Section 5.4.

   SF Identifier: An identifier of the SF.  The length of the SF
   Identifier depends on the type of the SF ID Type.  For example, if
   the SF Identifier is its IPv4 address, the SF Identifier should be 32
   bits.

3.3.  SF information Sub-TLV construction

   For each SFF in the SFP, it should send one COAM Reply corresponding
   to each one COAM Request.  If there is only one SF attached to the
   SFF in such SFP, only one SF information sub-TLV is included in the



Ao, et al.               Expires August 31, 2018                [Page 5]


Internet-Draft        SFC OAM for path consistency         February 2018


   on COAM Reply.  If there are several SFs attached to the SFF in the
   SFP, SF information sub-TLV is constructed as the following two
   cases.

   1.  Multiple SFs as hops of SFP:

   Multiple SFs attached to one SFF are the several hops of the SFP, the
   service indexes of these SFs are different.  Service function types
   of these SFs could be different or be same.  All these SFs
   information are included in one COAM Reply message, every SF
   information should be listed as separate SF information sub-TLVs in
   COAM Reply message.

   2.  Multiple SFs for load balance:

   Multiple SFs are attached to one SFF for load balance, that means
   only one SF will be transmitted for one traffic flow.  These SFs have
   the same Service Function Type, Service Index.  For this case, the SF
   identifiers of all these SFs will be listed in the SF Identifiers
   field in a single SF information sub-TLV of COAM Reply message.  The
   number of these SFs can be calculated according to SF ID Type and the
   value of Length field of the sub-TLV.

4.  Security Considerations

   Security considerations discussed in [I-D.ietf-sfc-nsh] apply to this
   document.

   In addition, since Service Function sub-TLV discloses information
   about the RSP the spoofed COAM Request packet may be used to obtain
   network information, it is RECOMMENDED that implementations provide a
   means of checking the source addresses of COAM Request messages,
   specified in SFC Source TLV [I-D.wang-sfc-multi-layer-oam], against
   an access list before accepting the message.

5.  IANA Considerations

5.1.  COAM Message Types

   IANA is requested to assign values from its Message Types sub-
   registry in SFC Echo Request/Echo Reply Message Types registry as
   follows:









Ao, et al.               Expires August 31, 2018                [Page 6]


Internet-Draft        SFC OAM for path consistency         February 2018


         +-------+------------------------------+---------------+
         | Value |         Description          | Reference     |
         +-------+------------------------------+---------------+
         | TBA1  | SFP Consistency Echo Request | This document |
         | TBA2  |  SFP Consistency Echo Reply  | This document |
         +-------+------------------------------+---------------+

      Table 1: SFP Consistency Echo Request/Echo Reply Message Types

5.2.  SFF Information Record TLV Type

   IANA is requested to assign new type value from SFC OAM TLV Type
   registry as follows:

          +-------+-----------------------------+---------------+
          | Value |         Description         | Reference     |
          +-------+-----------------------------+---------------+
          | TBA3  | SFF Information Record Type | This document |
          +-------+-----------------------------+---------------+

                      Table 2: SFF-Information Record

5.3.  SF Information Sub-TLV Type

   IANA is requested to assign new type value from SFC OAM TLV Type
   registry as follows:

                +-------+----------------+---------------+
                | Value |  Description   | Reference     |
                +-------+----------------+---------------+
                | TBA4  | SF Information | This document |
                +-------+----------------+---------------+

                   Table 3: SF-Information Sub-TLV Type

5.4.  SF Identifier Types

   IANA is requested create in the registry SF Types the new sub-
   registry SF Identifier Types.  All code points in the range 1 through
   191 in this registry shall be allocated according to the "IETF
   Review" procedure as specified in [RFC8126] and assign values as
   follows:









Ao, et al.               Expires August 31, 2018                [Page 7]


Internet-Draft        SFC OAM for path consistency         February 2018


          +------------+-------------+-------------------------+
          | Value      | Description | Reference               |
          +------------+-------------+-------------------------+
          | 0          |   Reserved  | This document           |
          | TBA6       |     IPv4    | This document           |
          | TBA7       |     IPv6    | This document           |
          | TBA8       |     MAC     | This document           |
          | TBA8+1-191 |  Unassigned | IETF Review             |
          | 192-251    |  Unassigned | First Come First Served |
          | 252-254    |  Unassigned | Private Use             |
          | 255        |   Reserved  | This document           |
          +------------+-------------+-------------------------+

                        Table 4: SF Identifier Type

6.  Acknowledgements

   Thanks to John Drake for his review and the reference to the work on
   BGP Control Plane for NSH SFC.

7.  References

7.1.  Normative References

   [I-D.ietf-bess-nsh-bgp-control-plane]
              Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L.
              Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess-
              nsh-bgp-control-plane-02 (work in progress), October 2017.

   [I-D.ietf-sfc-nsh]
              Quinn, P., Elzur, U., and C. Pignataro, "Network Service
              Header (NSH)", draft-ietf-sfc-nsh-28 (work in progress),
              November 2017.

   [I-D.wang-sfc-multi-layer-oam]
              Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Multi-
              Layer Active OAM for Service Function Chains in Networks",
              draft-wang-sfc-multi-layer-oam-10 (work in progress),
              September 2017.

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







Ao, et al.               Expires August 31, 2018                [Page 8]


Internet-Draft        SFC OAM for path consistency         February 2018


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

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

   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


   Zhonghua Chen
   China Telecom
   No.1835, South PuDong Road
   Shanghai  201203
   China

   Phone: +86 18918588897
   Email: 18918588897@189.cn






Ao, et al.               Expires August 31, 2018                [Page 9]


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