Internet DRAFT - draft-song-ippm-ioam-tunnel-mode
draft-song-ippm-ioam-tunnel-mode
ippm H. Song, Ed.
Internet-Draft Z. Li
Intended status: Informational T. Zhou
Expires: December 27, 2018 Z. Wang
Huawei
June 25, 2018
In-situ OAM Processing in Tunnels
draft-song-ippm-ioam-tunnel-mode-00
Abstract
This document describes the In-situ OAM (iOAM) processing behavior in
a network with tunnels. Specifically, the iOAM processing in tunnels
with the uniform model and the pipe model is discussed. The
procedure is applicable to different type of tunnel protocols.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
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 December 27, 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
Song, et al. Expires December 27, 2018 [Page 1]
Internet-Draft IOAM Tunnel Mode June 2018
(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. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Uniform Model . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. U1: IOAM Domain Starts and Ends outside of a Tunnel . . . 3
2.2. U2: IOAM Domain Starts and Ends within a Tunnel . . . . . 4
2.3. U3: IOAM Domain Starts and Ends at any Nodes . . . . . . 4
2.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 5
3. Pipe Model . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. P1: IOAM Domain Starts and Ends outside of a Tunnel . . . 5
3.2. P2: IOAM Domain Starts and Ends within a Tunnel . . . . . 5
3.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 5
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Motivation
In-situ OAM (iOAM) records OAM data associated with user packets
while these packets traverse a network
[I-D.brockners-inband-oam-requirements]. The iOAM instruction and
data are kept in an iOAM header which is defined in
[I-D.ietf-ippm-ioam-data]. The iOAM header needs to be encapsulated
in a packet's transport protocol header in order to be processed by
the network nodes who are capable of iOAM processing. So far, the
iOAM header encapsulation methods have been defined for several
protocols, including IPv6, VXLAN-GPE, NSH, SRv6
[I-D.brockners-inband-oam-transport],[I-D.ietf-sfc-ioam-nsh], GENEVE
[I-D.brockners-ippm-ioam-geneve], GRE [I-D.weis-ippm-ioam-gre], and
some others.
While the original scope of iOAM is purposely confined to a single
network domain for simplicity, the authentic E2E data collection
capability of iOAM is invaluable to network operators. In reality,
Song, et al. Expires December 27, 2018 [Page 2]
Internet-Draft IOAM Tunnel Mode June 2018
especially in carrier networks, a user packet may traverse several
network domains and pass through various tunnels for QoS, traffic
engineering, or public network traversal. To extend the scope of
iOAM's applicability and fully realize iOAM's potential, we need to
consider various network conditions. In this document, we describe
how iOAM should be processed in a network with tunnels.
A tunneling protocol usually needs to add another layer of protocol
header (i.e., the tunnel header) over the original packet. Within a
tunnel, only the outermost tunnel header is supposed to be processed
by a network node. Therefore, depending on the locations where the
iOAM header is encapsulated/decapsulated and the tunnel operation
mode, the iOAM processing is also different.
In general, there are two modes of tunnel operations: the Uniform
Model and the Pipe Model. The Uniform Model treats the nodes in a
tunnel uniformly as the nodes outside of the tunnel on an E2E path.
On the contrary, the Pipe Model abstracts all the nodes between the
tunnel ingress and egress as a circuit so no nodes in the tunnel is
visible to the nodes outside of the tunnel. The iOAM processing
behavior is discussed for each mode as follows.
2. Uniform Model
2.1. U1: IOAM Domain Starts and Ends outside of a Tunnel
In this case, a tunnel is fully in between the head node and the end
node of an iOAM path. This includes the situation that the tunnel
ingress coincides with the iOAM head node and/or the tunnel egress
coincides with the iOAM end node. The iOAM header handling for
different situation is described as follows:
o iOAM head node is outside of the tunnel: The iOAM header is
encapsulated into the original packet and processed.
o iOAM head node is the tunnel ingress: The iOAM header is
encapsulated into the original packet and processed. The iOAM
header is copied from the original packet and encapsulated into
the underlay protocol header.
o iOAM end node is outside of the tunnel: The iOAM header is
decapsulated from the original packet after iOAM processing.
o iOAM end node is the tunnel egress: The iOAM header in the
underlay protocol header is processed as usual. After the tunnel
header is removed and the original packet is exposed, the iOAM
header is copied to overwrite the original packet's iOAM header.
Song, et al. Expires December 27, 2018 [Page 3]
Internet-Draft IOAM Tunnel Mode June 2018
After the iOAM processing is finished, the iOAM header is removed
from the original packet.
o Other nodes in the iOAM domain: If the node is outside or inside
of the tunnel, the iOAM header encapsulated in the outermost
protocol header is processed. If the node is the tunnel ingress,
the iOAM header in the original packet needs to be copied and
encapsulated into the underlay protocol header. If the node is
the tunnel egress, the iOAM header in the underlay protocol header
needs to be copied to overwrite the iOAM header in the original
packet.
2.2. U2: IOAM Domain Starts and Ends within a Tunnel
There is nothing special about this case since the transport network
will not be aware of the tunnel. In this case, the iOAM is processed
as usual.
2.3. U3: IOAM Domain Starts and Ends at any Nodes
For extra flexibility, the iOAM domain can be configured to start and
end at any node (e.g., in or out of a tunnel). The iOAM header
handling for different situation is described as follows:
o iOAM head node is outside of the tunnel: The iOAM header is
encapsulated in the original packet.
o iOAM head node is the tunnel ingress: The iOAM header is
encapsulated in the original packet first and processed. Then the
iOAM header is copied from the original packet and encapsulated
into the underlay protocol header. Meanwhile, the iOAM header in
the original packet must be removed.
o iOAM head node is in the tunnel: The iOAM header is encapsulated
in the underlay protocol header and processed.
o iOAM head node is the tunnel egress: The iOAM header is
encapsulated in the underlay protocol header first and processed.
When the tunnel header is removed, the iOAM header is copied from
the underlay protocol header and encapsulated into the original
packet.
o iOAM end node is outside of the tunnel: The iOAM header is
decapsulated from the original packet.
o iOAM end node is the tunnel ingress: The iOAM header is
decapsulated from the original packet.
Song, et al. Expires December 27, 2018 [Page 4]
Internet-Draft IOAM Tunnel Mode June 2018
o iOAM end node is in the tunnel: The iOAM header is decapsulated
from the underlay protocol header.
o iOAM end node is the tunnel egress: The iOAM header is removed
with the underlay protocol header.
o Tunnel ingress is in the IOAM domain: The iOAM header is
decapsulated from the original packet and encapsulated in the
underlay protocol header.
o Tunnel egress is in the iOAM domain: The iOAM header in the
underlay protocol header is encapsulated into the original packet.
2.4. Discussion
U1 achieves the best implementation efficiency since it eliminates
one encapsulation or decapsulation operation while U3 achieves the
best flexibility and reduces the packet overhead.
Since a tunnel usually aggregates multiple flows, so U2 (or U3 when
the iOAM head node is in a tunnel) can only conduct iOAM at the
tunnel granularity and on aggregated flows.
3. Pipe Model
3.1. P1: IOAM Domain Starts and Ends outside of a Tunnel
This case includes the situation that the tunnel ingress coincides
with the iOAM head node and/or the tunnel egress coincides with the
iOAM end node.
In this mode, the iOAM header only exists in the original packet. It
is not copied to the tunnel header. Within the tunnel, the iOAM
header is invisible to the underlay network so it is not processed.
At the tunnel ingress, the iOAM header is processed before the tunnel
header is applied. At the tunnel egress, the iOAM header is
processed after the tunnel header is removed. To the iOAM header,
the entire tunnel appears to be just one hop.
3.2. P2: IOAM Domain Starts and Ends within a Tunnel
This mode is identical to U2.
3.3. Discussion
In P1, the hop-by-hop iOAM data is missing for the tunnel. However,
this mode also provides a convenient way to pass through third party
Song, et al. Expires December 27, 2018 [Page 5]
Internet-Draft IOAM Tunnel Mode June 2018
tunnels in which either the iOAM is not supported or the tunnel
operators do not participate in the iOAM service.
On the other hand, the tunnel operators can support iOAM
independently to monitor the tunnel performance using the mode of P2.
In this case, U1 can also be applied without any confliction, so both
underlay and overlay can be monitored by different entities.
When iOAM works in the E2E operation mode as described in
[I-D.ietf-ippm-ioam-data], any tunnel on the path should be
configured to the Pipe model in order to avoid the unnecessary iOAM
header encapsulation/decapsulation.
4. Examples
Examples will be added in future revisions.
5. Security Considerations
TBD
6. IANA Considerations
N/A
7. Contributors
TBD.
8. Acknowledgments
TBD.
9. References
9.1. Normative References
[I-D.brockners-inband-oam-transport]
Brockners, F., Bhandari, S., Govindan, V., Pignataro, C.,
Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes,
D., Lapukhov, P., and R. Chang, "Encapsulations for In-
situ OAM Data", draft-brockners-inband-oam-transport-05
(work in progress), July 2017.
Song, et al. Expires December 27, 2018 [Page 6]
Internet-Draft IOAM Tunnel Mode June 2018
[I-D.brockners-ippm-ioam-geneve]
Brockners, F., Bhandari, S., Govindan, V., Pignataro, C.,
Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes,
D., Lapukhov, P., and R. Chang, "Geneve encapsulation for
In-situ OAM Data", draft-brockners-ippm-ioam-geneve-01
(work in progress), June 2018.
[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., daniel.bernier@bell.ca, d., and J. Lemon,
"Data Fields for In-situ OAM", draft-ietf-ippm-ioam-
data-02 (work in progress), March 2018.
[I-D.ietf-sfc-ioam-nsh]
Brockners, F., Bhandari, S., Govindan, V., Pignataro, C.,
Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes,
D., Lapukhov, P., and R. Chang, "NSH Encapsulation for In-
situ OAM Data", draft-ietf-sfc-ioam-nsh-00 (work in
progress), May 2018.
[I-D.weis-ippm-ioam-gre]
Weis, B., Brockners, F., crhill@cisco.com, c., Bhandari,
S., Govindan, V., Pignataro, C., Gredler, H., Leddy, J.,
Youell, S., Mizrahi, T., Kfir, A., Gafni, B., Lapukhov,
P., and M. Spiegel, "GRE Encapsulation for In-situ OAM
Data", draft-weis-ippm-ioam-gre-00 (work in progress),
March 2018.
[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>.
9.2. Informative References
[I-D.brockners-inband-oam-requirements]
Brockners, F., Bhandari, S., Dara, S., Pignataro, C.,
Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi,
T., <>, P., and r. remy@barefootnetworks.com,
"Requirements for In-situ OAM", draft-brockners-inband-
oam-requirements-03 (work in progress), March 2017.
Authors' Addresses
Song, et al. Expires December 27, 2018 [Page 7]
Internet-Draft IOAM Tunnel Mode June 2018
Haoyu Song (editor)
Huawei
2330 Central Expressway
Santa Clara
USA
Email: haoyu.song@huawei.com
Zhenbin Li
Huawei
156 Beiqing Road
Beijing, 100095
P.R. China
Email: lizhenbin@huawei.com
Tianran Zhou
Huawei
156 Beiqing Road
Beijing, 100095
P.R. China
Email: zhoutianran@huawei.com
Zhongzhen Wang
Huawei
156 Beiqing Road
Beijing, 100095
P.R. China
Email: wangzhongzhen@huawei.com
Song, et al. Expires December 27, 2018 [Page 8]
