[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
SPRING                                                            Y.Qiu
Internet-Draft                                                     J.Ye
Intended status: Standards Track                                   H.Li
Expires: December 5, 2021                         H3C Technology Co.LTD
                                                           June 3, 2021






     Data Fields Encapsulation Model of In-situ OAM in SRv6 Network
               draft-qiu-spring-srv6-ioam-encap-model-00

Abstract

   OAM and PM information from the SR endpoints can be piggybacked in
   the data packet.  The OAM and PM information piggybacking in the
   data packets is also known as In-situ OAM (IOAM). IOAM records
   OAM information within the packet while the packet traverses a
   particular network domain.  The term "in-situ" refers to the fact
   that the IOAM data fields are added to the data packets rather than
   being sent within probe packets specifically dedicated to OAM.
   This document defines the data fields encapsulation model of IOAM
   TLV in SRv6 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 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 July 15, 2021.



Qiu, et al.               Expires December 5, 2021             [Page 1]


Internet-Draft      Data Encapsulation Model of IOAM TLV


Copyright Notice

   Copyright (c) 2020 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  . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Requirement Language  . . . . . . . . . . . . . . . . . .  3
     2.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .  3
   3. Data Encapsulation Model of In-situ OAM  . . . . . . . . . . .  4
     3.1. Pipe Model . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.2. Uniform Model  . . . . . . . . . . . . . . . . . . . . . .  5
   4. In-situ OAM Process Example For Uniform Model  . . . . . . . .  5
   5. In-situ OAM Process Example For Pipe Model . . . . . . . . . .  6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  8
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  9








Qiu, et al.               Expires December 5, 2021             [Page 2]


Internet-Draft      Data Encapsulation Model of IOAM TLV


1.  Introduction

   OAM and PM information from the SR endpoints can be piggybacked in
   the data packet.  The OAM and PM information piggybacking in the
   data packets is also known as In-situ OAM (IOAM). IOAM records
   OAM information within the packet while the packet traverses a
   particular network domain.  The term "in-situ" refers to the fact
   that the IOAM data fields are added to the data packets rather than
   being sent within probe packets specifically dedicated to OAM.

   This document defines the data fields encapsulation model of IOAM
   TLV for the Segment Routing headend with H.Encaps encapsulation
   behavior in SRv6 network.

   The IOAM data fields carried are defined in
   [I-D.ietf-ippm-ioam-data], and can be used for various use-cases
   including Performance Measurement(PM) and Proof-of-Transit (PoT).

2.  Conventions

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

2.2.  Abbreviations

   Abbreviations used in this document:

   IOAM    In-situ Operations, Administration, and Maintenance

   OAM     Operations, Administration, and Maintenance

   PM      Performance Measurement

   PoT     Proof-of-Transit

   SR      Segment Routing

   SRH     SRv6 Header

   SRv6    Segment Routing with IPv6 Data plane



Qiu, et al.               Expires December 5, 2021             [Page 3]


Internet-Draft      Data Encapsulation Model of IOAM TLV


3. Data Encapsulation Model of In-situ OAM

    The encapsulation format of IOAM TLV and where to fill it in SRv6
    network are already defined in [I-D.draft-ali-spring-ioam-srv6]. It
    elaborates on the process of encapsulating IOAM data by individual
    nodes of SRV6. However, it lacks a process for how to perform IOAM
    detection when encapsulating an SRV6 packet, For example, in
    inter-AS scenarios and in scenarios exist to protect tunnel paths.

    This document defines two models for IOAM data fields encapsulation
    operation: Pipe and Uniform Models.

3.1. Pipe Model

   In the Pipe Model, the SRv6 network acts like a circuit when IOAM
   data packets traverse the network such that only the IOAM data of
   ingress and egress nodes are collected to report to analyzer with
   the same Flow Monitoring Identification (FlowMonID) and same type.
   It means that only ingress node and egress node of SRv6 network are
   visible to the analyzer. The analyzer can only calculate the
   end-to-end performance of the SRV6 network.

             ========== SRv6 packet ========================>

                 +--Transit--(d)-...-Transit--(d)---+
                /          (outer header)            \
              (d)                                    (d)
              /                                        \
   >--(D)--Ingress...............(D).................Egress--(D)->
           (Push)           (inner header)           (Pop)

   (d) represents the data field values in the outer SRH
   (D) represents the data field values in the encapsulated header

   This picture shows data field encapsulation mothod of In-situ OAM
   processing in the Pipe Model.  The outer IOAM data fields in packet
   have no relationship to the inner.

   The network nodes encapsulate IOAM TLV according to local
   configuration with a new FlowMonID and a new IOAM-Trace-Type value,
   and do not care about the IOAM information that is already carried
   in the packet.

   The Pipe model is more suitable for end-to-end measurement
   scenarios, since the intermediate router does not need to collect
   and report data.



Qiu, et al.               Expires December 5, 2021             [Page 4]


Internet-Draft      Data Encapsulation Model of IOAM TLV


3.2. Uniform Model

   In the Uniform Model, all the nodes collect IOAM data according to
   the same IOAM-Trace-Type, and report IOAM data to analyzer with the
   same FlowMonID. So the analyzer can calculate hop-by-hop forwarding
   performance based on the IOAM data received from all nodes in the
   SRv6 network.

             ========== SRv6 packet ========================>

                 +--Transit--(D)-...-Transit--(D)---+
                /          (outer header)            \
              (D)                                    (D)
              /                                        \
   >--(D)--Ingress...............(D).................Egress--(D)->
           (Push)           (inner header)           (Pop)

   (D) represents the data field values in the corresponding IOAM TLV

   This picture shows data field encapsulation of In-situ OAM
   processing for a Uniform Model.

   With the Uniform model, the inner and outer IOAM data-fields are
   synchronized, including FlowMonID IOAM-trace-Type IOAM-option-Types,
   etc. The contents of IOAM fields are uniform before and after
   tunnel encapsulation. The easy way to do it is to copy directly form
   the inner IOAM TLV.

   Uniform model is suitable for postcard IOAM in
   Hop-by-Hop measurement scenario. Because cannot see how many routers
   are contained in another autonomous system in inter-AS scenario,
   Uniform mode is not applicable to passport IOAM measurement.
   Postcard IOAM measurement in inter-AS scenario is outside the scope
   of this document.

4. In-situ OAM Process Example For Uniform Model

          +---------------------+  +---------------------+
          |         AS1         |  |         AS2         |
   +-+-+  | +-+-+  +-+-+  +-+-+ |  | +-+-+  +-+-+  +-+-+ |  +-+-+
   +CE1+--+-+PE1+--+P1 +--+PE2+-+--+-+PE3+--+P2 +--+PE4+-+--+CE2+
   +-+-+  | +-+-+  +-+-+  +-+-+ |  | +-+-+  +-+-+  +-+-+ |  +-+-+
          |                     |  |                     |
          +---------------------+  +---------------------+

   Figure 1: Example Inter-AS Scenario of In-situ OAM



Qiu, et al.               Expires December 5, 2021             [Page 5]


Internet-Draft      Data Encapsulation Model of IOAM TLV


   This figure shows an example of In-situ OAM used in across SRv6
   autonomous systems. PE1, P1 and PE2 are SRv6-capable nodes in
   autonomous system AS1. PE3, P2, PE4 are SRv6-capable nodes in
   autonomous system AS2. An SRv6 instantiation of a Binding SID (BSID)
   of PE3 is used to cross autonomous system. When the traffic is
   sent from CE1 to CE2, the process is:

   1) PE1 receives the packets and encapsulates SRH with a list
   of segments destined to BSID of PE3, which is instantiated as an
   ordered list of SRv6 SIDs <PE1, P1, PE2, BSID>. As part of the SRH
   encapsulation, AS1's ingress node PE1 adds IOAM TLV to the SRH of
   the packets. The IOAM TLV contains FlowMonID and IOAM-trace-Type
   fields. The FlowMonID is used to identify a monitored flow.
   IOAM-Trace-Type is a 24-bit identifier which specifies which data
   types are used in this node.

   2) When the packet flow arrives in P1, P1 collects the IOAM data
   based on the IOAM-trace-Type field in IOAM TLV of the packet,
   and reports the collected data to the analyzer.

   3) When the packet flow arrives in PE3, PE3 also collects IOAM data
   based on the IOAM-trace-Type field in IOAM TLV of packet, and
   reports the collected data to the analyzer. After that PE3 matches
   Binding SID with H.encaps behavior, and pushes a outer IPv6 header
   with its own SRH according SRv6 policy of BSID, which contains an
   SID list {PE3, P2, PE4}.

   4) PE3 encapsulates an outer IOAM TLV to SRH in the outer IPv6
   header according local configuration and the data fields of IOAM TLV
   carried in packet. The outer IOAM data-fields synchronize IOAM
   information from the inner IOAM TLV, such as FlowMonID,
   IOAM-trace-Type, IOAM-option-Types and so on.

   5) When the packet flow arrives in P2, the routers in AS2 collect
   IOAM data based on the IOAM-trace-Type in IOAM TLV of the outer SRH.

   6) PE4 removes the outer IPv6 header, and recovers the inner
   packet. Subsequent devices continue to forward packet according to
   the inner IPv6 header and collect IOAM data according to the inner
   IOAM TLV.

   Because the same FlowMonID is used throughout the forward path
   across multiple autonomous systems, the analyzer detects and
   identifies anomalies in the network based on the collected data
   reported by each of the devices, so as to accurately detect the
   delay and packet loss of each service, making the network quality
   service level agreement (SLA) visible in real time, and achieving
   rapid fault delimitation and location.



Qiu, et al.               Expires December 5, 2021             [Page 6]


Internet-Draft      Data Encapsulation Model of IOAM TLV


5. In-situ OAM Process Example For Pipe Model

   The Pipe model is also illustrated using Figure 1. When the traffic
   is sent from CE1 to CE2, the process is:

   1) PE1 receives the packets and encapsulates SRH with a list
   of segments destined to BSID of PE3, which is instantiated as an
   ordered list of SRv6 SIDs <PE1, P1, PE2, BSID>. As part of the SRH
   encapsulation, AS1's ingress node PE1 adds IOAM TLV to the SRH of
   the packets.

   2) When the packet flow arrives in P1 and PE2, P1 and PE2 collect
   the IOAM data based on the IOAM-trace-Type field in IOAM TLV of the
   packet, and report the collected data to the analyzer.

   3) When the packet flow arrives in PE3, PE3 also collects IOAM data
   based on the IOAM-trace-Type field in IOAM TLV of packet, and
   reports the collected data to the analyzer. After that PE3 matches
   Binding SID with H.encaps behavior, and pushes a outer IPv6 header
   with its own SRH according SRv6 policy of BSID, which contains an
   SID list {PE3, P2, PE4}.

   4) If configuration requires, PE3 identifies target traffic flow
   that require IOAM detection based on the local configuration, and
   encapsulates the IOAM TLV in the outer SRH. Then PE3 assigns a new
   FlowMonID to the target flow, populates the IOAM data fields with
   the new IOAM-trace-Type and IOAM-option-Types.

   5) When the packet flow arrives in P2, the routers in AS2 collect
   IOAM data based on the IOAM-trace-Type in IOAM TLV of the outer SRH.

   6) PE4 removes the outer IPv6 header, and recovers the inner
   packet. Subsequent devices continue to forward packet according to
   the inner IPv6 header and collect IOAM data according to the inner
   IOAM TLV.

   Because the two AS's use different FlowMonIDs for the same flow,
   according to the FlowMonID identified by PE1, the analyzer can only
   calculate the forwarding performance of this flow between PE3 and
   PE4 in AS2. It is not possible to measure performance data between
   other nodes in AS2.

6.  IANA Considerations

   No requirements for IANA.



Qiu, et al.               Expires December 5, 2021             [Page 7]


Internet-Draft      Data Encapsulation Model of IOAM TLV


7.  Security Considerations

   TBA

8.  Acknowledgements

   The authors would like to thank people for their comments to this
   work.

9.  References

9.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,
              <https://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, <https://www.rfc-editor.org/info/rfc8174>.

   [I-D.ietf-ippm-ioam-data]  Brockners, F., Bhandari, S., Pignataro,
              C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T.,
              Mozes, D., Lapukhov, P., Chang, R., and Bernier, D.,
              "Data Fields for In-situ OAM", draft-ietf-ippm-ioam-data,
              work in progress.

   [I-D.draft-ali-spring-ioam-srv6]  Ali, Z., Gandhi, R., Filsfils, C.,
              Brockners, F., Nainar, N., Pignataro, C., Li, C.,
              Chen, M., Dawra, G.,  "Segment Routing Header
              encapsulation for In-situ OAM Data",
              draft-ali-spring-ioam-srv6, work in progress.

9.2.  Informative References

   [I-D.6man-extension-header-insertion]  D. Voyer, et al., "Insertion
              of IPv6 Segment Routing Headers in a Controlled Domain",
              draft-voyer-6man-extension-header-insertion, work in
              progress.

   [I-D.ietf-6man-ipv6-alt-mark]
              Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
              Pang, "IPv6 Application of the Alternate Marking Method",
              draft-ietf-6man-ipv6-alt-mark-04 (work in progress),
              March 2021.


Qiu, et al.               Expires December 5, 2021             [Page 8]


Internet-Draft      Data Encapsulation Model of IOAM TLV


Authors' Addresses

   Yuanxiang Qiu
   H3C Technology Co.LTD, No.466 Changhe Rd.
   Hangzhou  310008
   China

   Email: qiuyuanxiang@h3c.com

   Jinrong Ye
   H3C Technology Co.LTD

   Email: jrong.y@h3c.com

   Hao Li
   H3C Technology Co.LTD

   Email: lihao@h3c.com


















Qiu, et al.               Expires December 5, 2021             [Page 9]