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