BIER Working Group X. Min
Internet-Draft Z. Zhang
Intended status: Standards Track ZTE Corp.
Expires: July 12, 2021 Y. Liu
China Mobile
N. Nainar
C. Pignataro
Cisco Systems, Inc.
January 8, 2021
Bit Index Explicit Replication (BIER) Encapsulation for In-situ OAM
(IOAM) Data
draft-xzlnp-bier-ioam-01
Abstract
In-situ Operations, Administration, and Maintenance (IOAM) collects
operational and telemetry information while the packet traverses a
particular network domain. Bit Index Explicit Replication (BIER) is
an architecture that provides optimal multicast forwarding through a
"multicast domain", without requiring intermediate routers to
maintain any per-flow state or to engage in an explicit tree-building
protocol. The BIER header contains a bit-string in which each bit
represents exactly one egress router to forward the packet to. This
document outlines the requirements to carry IOAM data in BIER header
and specifies how IOAM data fields are encapsulated in BIER header.
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 12, 2021.
Min, et al. Expires July 12, 2021 [Page 1]
Internet-Draft BIER Encap for IOAM Data January 2021
Copyright Notice
Copyright (c) 2021 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. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements to carry IOAM data in BIER header . . . . . . . 3
4. IOAM data fields encapsulation in BIER header . . . . . . . . 4
5. Considerations . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Discussion of the encapsulation approach . . . . . . . . 6
5.2. IOAM and the use of the BIER OAM bits . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
In-situ Operations, Administration, and Maintenance (IOAM) collects
operational and telemetry information while the packet traverses a
particular network domain. [I-D.ietf-ippm-ioam-data] defines
different IOAM data fields used to record various telemetry data from
the transit nodes. The term "in-situ" refers to the fact that the
IOAM data fields are added to the data packets rather than being sent
within packets specifically dedicated to OAM.
Bit Index Explicit Replication (BIER), as defined in [RFC8279], is an
architecture that provides optimal multicast forwarding through a
"multicast domain", without requiring intermediate routers to
maintain any per-flow state or to engage in an explicit tree-building
Min, et al. Expires July 12, 2021 [Page 2]
Internet-Draft BIER Encap for IOAM Data January 2021
protocol. The BIER header, as defined in [RFC8296], contains a bit-
string in which each bit represents exactly one egress router to
forward the packet to.
This document outlines the requirements to carry IOAM data in BIER
header and specifies how IOAM data fields are encapsulated in BIER
header.
2. Conventions Used in This Document
2.1. 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.
2.2. Abbreviations
Abbreviations used in this document:
BFER: Bit Forwarding Egress Router
BFIR: Bit Forwarding Ingress Router
BIER: Bit Index Explicit Replication
GRE: Generic Routing Encapsulation
IOAM: In-situ Operations, Administration, and Maintenance
OAM: Operations, Administration, and Maintenance
3. Requirements to carry IOAM data in BIER header
[I-D.ietf-bier-use-cases] lists many use cases for BIER. Usually
there are many multicast flows within one network domain, and some of
the multicast flows, such as live video and real-time meeting, are
sensitive to packet loss, delay and other factors. The network
operator wants to know the real-time statistics for these flows, such
as delay, sequence, the ingress/egress interface, and the usage of
buffer.
So methods are needed for measuring the real-time transportation
guarantee of BIER packet. Performance measurement function defined
in [I-D.ietf-bier-pmmm-oam] can be used for measuring packet loss and
Min, et al. Expires July 12, 2021 [Page 3]
Internet-Draft BIER Encap for IOAM Data January 2021
delay. This document attempts to provide a way to collect on-path
operational and telemetry information through in-situ OAM.
4. IOAM data fields encapsulation in BIER header
The BIER header is defined in [RFC8279]. The BIER OAM header that
follows BIER header is defined in [I-D.ietf-bier-ping]. IOAM-Data-
Fields can either be carried in BIER using a new type of OAM message
which follows the BIER OAM header (referred to as option 1), or be
carried in BIER using a new next protocol header which immediately
follows the BIER header (referred to as option 2). In this document,
option 2 is selected and the reason is discussed in Section 5.1. An
IOAM header is added containing the different IOAM-Data-Fields
defined in [I-D.ietf-ippm-ioam-data].
In an administrative domain where IOAM is used, insertion of the IOAM
header in BIER is enabled at the BFIRs, which also serve as IOAM
encapsulating nodes by means of configuration, deletion of the IOAM
header in BIER is enabled at the BFERs, which also serve as IOAM
decapsulating nodes by means of configuration.
The Encapsulation format for IOAM over BIER is defined as follows:
Min, et al. Expires July 12, 2021 [Page 4]
Internet-Draft BIER Encap for IOAM Data January 2021
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
| BIFT-id | TC |S| TTL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|Nibble | Ver | BSL | Entropy | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ B
|OAM|Rsv| DSCP |Proto = TBD| BFIR-id | I
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E
| BitString (first 32 bits) ~ R
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ BitString (last 32 bits) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
| IOAM-Type | IOAM HDR Len | Reserved | Next Proto| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I
| | O
| | A
~ IOAM Option and Data Space ~ M
| | |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
| |
| |
| Payload + Padding (L2/L3/...) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IOAM Encapsulation Format within BIER
The BIER header and fields are defined in [RFC8296]. Within the BIER
header, a 6-bit field as "Proto" (Next Protocol) is used to identify
the type of the payload immediately following the BIER header, The
"Proto" value is set to TBD when the IOAM header is present.
The IOAM related fields in BIER are defined as follows:
IOAM-Type: 8-bit field defining the IOAM Option Type, as defined
in Section 8.1 of [I-D.ietf-ippm-ioam-data].
IOAM HDR Len: 8-bit unsigned integer. Length of the IOAM header
in 4-octet units.
Reserved: 10-bit reserved field MUST be set to zero upon
transmission and ignored upon receipt.
Min, et al. Expires July 12, 2021 [Page 5]
Internet-Draft BIER Encap for IOAM Data January 2021
Next Proto: 6-bit unsigned integer that identifies the type of
payload immediately following this IOAM option. The semantics of
this field are identical to the "Proto" field in [RFC8296].
IOAM Option and Data Space: IOAM option header and data is present
as specified by the IOAM-Type field, and is defined in Section 5
of [I-D.ietf-ippm-ioam-data].
Multiple IOAM-Option-Types MAY be included within the BIER
encapsulation. For example, if a BIER encapsulation contains two
IOAM-Option-Types preceding a data payload, the Next Proto field of
the first IOAM option will contain the value of TBD, while the Next
Proto field of the second IOAM option will contain the "BIER Next
Protocol" number indicating the type of the data payload. Each IOAM
Option-Type MUST occur at most once within the same BIER
encapsulation header.
5. Considerations
This section summarizes a set of considerations on the overall
approach taken for IOAM data encapsulation in BIER, as well as
deployment considerations.
5.1. Discussion of the encapsulation approach
Both the options described in section 4 are supposed to be feasible,
nevertheless this document needs to select one as standardized
encapsulation for IOAM over BIER. Considering the fact that the
encapsulation format option 2 using a new next protocol header is
more concise than option 1 using a new type of OAM message, and many
other transport protocols, e.g. GRE, use a new next protocol header
to encapsulate IOAM data, the encapsulation format option 2 is
selected as the standardized one.
5.2. IOAM and the use of the BIER OAM bits
[RFC8296] defines a two-bits long field, referred to as OAM.
[I-D.ietf-bier-pmmm-oam] describes how to use the two-bits OAM field
for alternate marking performance measurement method, and this
document would not change the semantics of the two-bits OAM field.
The BIER IOAM header and the BIER two-bits OAM field are orthogonal
and can co-exist in the same packet header, i.e. a BIER packet with
IOAM data can set the OAM field or not, and a BIER packet with OAM
field set can also carry IOAM data or not.
Min, et al. Expires July 12, 2021 [Page 6]
Internet-Draft BIER Encap for IOAM Data January 2021
6. Security Considerations
This document does not raise any additional security issues beyond
those of the specifications referred to in the list of normative
references.
7. IANA Considerations
In the "BIER Next Protocol Identifiers" registry defined in
[RFC8296], a new Next Protocol Value for IOAM is requested from IANA
as follows:
+--------------------+---------------+-----------------+------------+
| BIER Next Protocol | Description | Semantics | Reference |
| Identifier | | Definition | |
+--------------------+---------------+-----------------+------------+
| TBD | In-situ OAM | Section 4 | This |
| | (IOAM) | | Document |
+--------------------+---------------+-----------------+------------+
Table 1: New BIER Next Protocol Identifier for IOAM
8. Acknowledgements
The authors would like to acknowledge Greg Mirsky for his thorough
review and very helpful comments.
9. References
9.1. Normative References
[I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in
progress), November 2020.
[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>.
Min, et al. Expires July 12, 2021 [Page 7]
Internet-Draft BIER Encap for IOAM Data January 2021
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>.
9.2. Informative References
[I-D.ietf-bier-ping]
Nainar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M.,
and G. Mirsky, "BIER Ping and Trace", draft-ietf-bier-
ping-07 (work in progress), May 2020.
[I-D.ietf-bier-pmmm-oam]
Mirsky, G., Zheng, L., Chen, M., and G. Fioccola,
"Performance Measurement (PM) with Marking Method in Bit
Index Explicit Replication (BIER) Layer", draft-ietf-bier-
pmmm-oam-09 (work in progress), December 2020.
[I-D.ietf-bier-use-cases]
Nainar, N., Asati, R., Chen, M., Xu, X., Dolganow, A.,
Przygienda, T., Gulko, A., Robinson, D., Arya, V., and C.
Bestler, "BIER Use Cases", draft-ietf-bier-use-cases-12
(work in progress), September 2020.
Authors' Addresses
Xiao Min
ZTE Corp.
Nanjing
China
Email: xiao.min2@zte.com.cn
Zheng(Sandy) Zhang
ZTE Corp.
Nanjing
China
Email: zhang.zheng@zte.com.cn
Min, et al. Expires July 12, 2021 [Page 8]
Internet-Draft BIER Encap for IOAM Data January 2021
Yisong Liu
China Mobile
Beijing
China
Email: liuyisong@chinamobile.com
Nagendra Kumar Nainar
Cisco Systems, Inc.
7200-11 Kit Creek Road
Research Triangle Park, NC 27709
United States
Email: naikumar@cisco.com
Carlos Pignataro
Cisco Systems, Inc.
7200-11 Kit Creek Road
Research Triangle Park, NC 27709
United States
Email: cpignata@cisco.com
Min, et al. Expires July 12, 2021 [Page 9]