Routing Area Working Group G. Mirsky
Internet-Draft Ericsson
Intended status: Standards Track E. Nordmark
Expires: April 16, 2017 Arista Networks
N. Kumar
D. Kumar
Cisco Systems, Inc.
M. Chen
Y. Li
Huawei Technologies
D. Mozes
Mellanox Technologies Ltd.
D. Dolson
Sandvine
I. Bagdonas
October 13, 2016

OAM Header for use in Overlay Networks
draft-ooamdt-rtgwg-ooam-header-01

Abstract

This document introduces Overlay OAM Header to be used in overlay networks to de-multiplex Overlay OAM protocols.

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 http://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 April 16, 2017.

Copyright Notice

Copyright (c) 2016 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 (http://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

New protocols that support overlay networks like VxLAN-GPE [I-D.ietf-nvo3-vxlan-gpe], GUE [I-D.ietf-nvo3-gue], Geneve [I-D.ietf-nvo3-geneve], BIER [I-D.ietf-bier-mpls-encapsulation], and NSH [I-D.ietf-sfc-nsh] support multi-protocol payload, e.g. Ethernet, IPv4/IPv6, and recognize Operations, Administration, and Maintenance (OAM) as one of distinct types. That ensures that Overlay OAM packets are sharing fate with Overlay data packet traversing the underlay.

This document introduces Overlay OAM Header to be used in overlay networks to de-multiplex Overlay OAM protocols.

1.1. Conventions used in this document

1.1.1. Terminology

Term "Overlay OAM" used in this document interchangeably with longer version "set of OAM protocols, methods and tools for Overlay networks".

NTP Network Time Protocol

PTP Precision Time Protocol

1.1.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 [RFC2119].

2. Overlay OAM Header

    
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |           Msg Type        |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Flags             |    Reserved   |   Next Prot   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                  OOAM Control Packet                          ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Overlay OAM Header format

The format of the Overlay OA Header is:

The OAM Header consists of the following fields:

    
  0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|          Reserved           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Flags field format

The format of the Flags field is:

  • T - Timestap block flag.
  • Reserved - must be set to all zeroes on transmission and ignored on receipt.

    
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  QTF  |  RTF  |                   Reserved                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Timestamp 1                         |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Timestamp 4                         |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       

Figure 3: Timestamp block format

The OOAM header may be followed by the Timestamp control block Figure 3 and then by OOAM Control Packet identified by the Msg Type field.

where: [RFC5905], is widely used and has long history of deployment. But it is the IEEE 1588 Precision Time Protocol (PTP) [IEEE.1588.2008] that is being broadly used to achieve high-quality clock synchronization. Converging between NTP and PTP time formats is possible but is not trivial and does come with cost, particularly when it is required to be performed in real time without loss of accuracy. And recently protocols that supported only NTP time format, like One-Way Active Measurement Protocol [RFC4656] and Two-Way Active Measurement Protocol [RFC5357], have been enchanced to support the PTP time format as well [I-D.ietf-ippm-twamp-time-format]. This document proposes to select PTP time format as default time format for Overlay OAM performance measurement. Hence QTF, RTF fields MUST be set to 0 if querer or responder use PTP time format respectively. If the querer or responder use the NTP time format, then QTF and/or RTF MUST be set to 1. Use of other values MUST be considered as error and MAY be reported.

  • QTF - Querier timestamp format
  • RTF - Responder timestamp format
  • Timestamp 1-4 - 64-bit timestamp values

Network Time Protocol (NTP), described in

3. IANA Considerations

IANA is requested to create new registry called "Overlay OAM".

3.1. OOAM Message Types

IANA is requested to create new sub-registry called "Overlay OAM Protocol Types" in the "Overlay OAM" registry. All code points in the range 1 through 15615 in this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC5226] . Remaining code points are allocated according to the Table 1:

Overlay OAM Protocol type
Value Description Reference
0 Reserved
1 - 15615 Unassigned IETF Review
15616 - 16127 Unassigned First Come First Served
16128 - 16143 Experimental This document
16144 - 16382 Private Use This document
16383 Reserved This document

3.2. OOAM Header Flags

IANA is requested to create sub-registry "Overlay OAM Header Flags" in "Overlay OAM" registry. Two flags are defined in this document. New values are assigned via Standards Action [RFC5226].

Overlay OAM Flags
Flags bit Description Reference
Bit 0 Timestamp field This document
Bit 1-15 Unassigned

4. Security Considerations

TBD

5. Acknowledgement

TBD

6. References

6.1. Normative References

, "
[IEEE.1588.2008]Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Standard 1588, July 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC5905] Mills, D., Martin, J., Burbank, J. and W. Kasch, Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010.

6.2. Informative References

[I-D.ietf-bier-mpls-encapsulation] Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J. and S. Aldrin, "Encapsulation for Bit Index Explicit Replication in MPLS Networks", Internet-Draft draft-ietf-bier-mpls-encapsulation-04, April 2016.
[I-D.ietf-ippm-twamp-time-format] Mirsky, G. and I. Meilik, "Support of IEEE-1588 time stamp format in Two-Way Active Measurement Protocol (TWAMP)", Internet-Draft draft-ietf-ippm-twamp-time-format-00, June 2016.
[I-D.ietf-nvo3-geneve] Gross, J. and I. Ganga, "Geneve: Generic Network Virtualization Encapsulation", Internet-Draft draft-ietf-nvo3-geneve-01, January 2016.
[I-D.ietf-nvo3-gue] Herbert, T., Yong, L. and O. Zia, "Generic UDP Encapsulation", Internet-Draft draft-ietf-nvo3-gue-04, July 2016.
[I-D.ietf-nvo3-vxlan-gpe] Kreeger, L. and U. Elzur, "Generic Protocol Extension for VXLAN", Internet-Draft draft-ietf-nvo3-vxlan-gpe-02, April 2016.
[I-D.ietf-sfc-nsh] Quinn, P. and U. Elzur, "Network Service Header", Internet-Draft draft-ietf-sfc-nsh-05, May 2016.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J. and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K. and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008.

Authors' Addresses

Greg Mirsky Ericsson EMail: gregimirsky@gmail.com
Erik Nordmark Arista Networks EMail: nordmark@acm.org
Nagendra Kumar Cisco Systems, Inc. EMail: naikumar@cisco.com
Deepak Kumar Cisco Systems, Inc. EMail: dekumar@cisco.com
Mach Chen Huawei Technologies EMail: mach.chen@huawei.com
Yizhou Li Huawei Technologies EMail: liyizhou@huawei.com
David Mozes Mellanox Technologies Ltd. EMail: davidm@mellanox.com
David Dolson Sandvine EMail: ddolson@sandvine.com
Ignas Bagdonas EMail: ibagdona@gmail.com