GRE Generic Associated Channel
draft-srinivas-intarea-gre-gach-00.txt

Abstract

RFC 5586 defines a Generic Associated Channel (G-ACh) mechanism for MPLS paths that enables multiplexing of auxiliary traffic over such paths along with the user traffic they carry. Such auxiliary traffic is commonly used for Operations, Administration, and Maintenance protocols that enable monitoring and management of the path. This document describes the applicability of the G-ACh mechanism to Generic Routing Encapsulation (GRE) tunnels.

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 March 30, 2012.

Copyright Notice

Copyright (c) 2011 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
• 1.1. Requirements Language
• 2. G-ACh Packet Encapsulation over GRE
• 2.1. Structure of a GRE Encapsulated G-ACh Packet
• 2.2. GRE Header
• 3. IANA Considerations
• 4. Security Considerations
• 5. References
• 5.1. Normative References
• 5.2. Informative References
• Authors' Addresses

1. Introduction

Generic Routing Encapsulation (GRE) [RFC2784] is a means of encapsulating one network layer protocol over another. This practice is commonly referred to as "tunneling". GRE deployments typically take the form of one or more logical point-to-point or point-to-multipoint tunnels.

As with other kinds of network links, a problem with logical tunnels is how they are monitored and managed. In some cases no special functionality is needed for this purpose beyond that provided by the underlying network layer. In other cases, however, more robust Operations, Administration, and Maintenance (OAM) functionality may be required. For example, a tunnel may be carrying critical traffic that is subject to a strict service level agreement, one that requires the service provider to monitor the tunnel continuously for connectivity faults and performance degradations.

A mechanism to facilitate such OAM functionality, the Generic Associated Channel (G-ACh), has been defined for tunnels based on Multiprotocol Label Switching (MPLS) in [RFC5586]. The G-ACh provides an auxiliary "side-channel" associated with each tunnel that can be used to carry a variety of OAM protocols over the tunnel so that it can be monitored and managed. Examples of OAM protocols defined for use over the G-ACh include Bidirectional Forwarding Detection (BFD) [RFC5880] and protocols for precision measurement of packet loss, delay, and throughput [RFC6374].

This document describes how the existing G-ACh mechanism can be used for GRE tunnels. The scope of this document is limited to description of the mechanism itself, and does not include discussions on applicability of specific G-ACh protocols to GRE tunnels.

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

2. G-ACh Packet Encapsulation over GRE

2.1. Structure of a GRE Encapsulated G-ACh Packet

As shown in [RFC2784], a GRE packet has the following form, with the outermost encapsulation layer shown at the top:

    +-------------------------------+
    |       Delivery Header         |
    +-------------------------------+
    |       GRE Header              |
    +-------------------------------+
    |       Payload Packet          |
    |                               |
    +-------------------------------+

The Delivery Header is the header for the underlying network layer over which the GRE packet is transported. It may be an IPv4 header or an IPv6 header. The GRE Header [RFC2890] follows the Delivery Header and identifies the format of the payload packet.

When the payload is a G-ACh message, the GRE packet has the following form:

    +------------------------------------+
    |           Delivery Header          |
    +------------------------------------+
    |           GRE Header               |
    +------------------------------------+
    |   Associated Channel Header (ACH)  |
    +------------------------------------+
    |           G-ACh Payload            |
    |                                    |
    +------------------------------------+

As specified in [RFC5586], the Associated Channel Header identifies the format of the G-ACh payload that follows.

2.2. GRE Header

The presence of the Associated Channel Header (ACH) is indicated by the Protocol Type field in the GRE header ([RFC2784] and [RFC2890]). The value of the Protocol Type field is an EtherType as used for next-layer protocol type identification in Ethernet frames. The EtherType registry is maintained by the Institute of Electrical and Electronics Engineers (IEEE) and also documented in the IANA "Ethernet Numbers" registry. The IEEE has allocated an EtherType for G-ACh packets as follows:

The format of the GRE header as documented in [RFC2890], when the payload is a G-ACh packet beginning with an Associated Channel Header, is:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C| |K|S| Reserved0       | Ver |     Protocol Type = G-ACh     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Checksum (optional)      |       Reserved1 (Optional)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Key (optional)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Sequence Number (Optional)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3. IANA Considerations

IANA is requested to verify that the IANA "Ethernet Numbers" registry reflects the IEEE allocation for the G-ACh EtherType.

4. Security Considerations

This document indicates how a Generic Associated Channel protocol packet can be carried inside a GRE packet. This encapsulation itself poses no security risks beyond those already documented for GRE and the G-ACh. When a G-ACh protocol is used for Operations, Administration, and Maintenance of GRE tunnels, the security considerations of that protocol also apply.

5. References

5.1. Normative References

5.2. Informative References

Authors' Addresses