Internet DRAFT - draft-srinivas-intarea-gre-gach

draft-srinivas-intarea-gre-gach






Internet Area Working Group                             P. Srinivas, Ed.
Internet-Draft                                             D. Frost, Ed.
Intended status: Standards Track                           Cisco Systems
Expires: March 30, 2012                               September 27, 2011


                     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



Srinivas & Frost         Expires March 30, 2012                 [Page 1]

Internet-Draft       GRE Generic Associated Channel       September 2011


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  G-ACh Packet Encapsulation over GRE . . . . . . . . . . . . . . 3
     2.1.  Structure of a GRE Encapsulated G-ACh Packet  . . . . . . . 3
     2.2.  GRE Header  . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     5.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     5.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6


































Srinivas & Frost         Expires March 30, 2012                 [Page 2]

Internet-Draft       GRE Generic Associated Channel       September 2011


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:





Srinivas & Frost         Expires March 30, 2012                 [Page 3]

Internet-Draft       GRE Generic Associated Channel       September 2011


       +-------------------------------+
       |       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:

   EtherType   Meaning
   ----------- ---------------------------------------------------
   (TBD)       Generic Associated Channel (G-ACh) packet [RFC5586]

   The format of the GRE header as documented in [RFC2890], when the



Srinivas & Frost         Expires March 30, 2012                 [Page 4]

Internet-Draft       GRE Generic Associated Channel       September 2011


   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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC2890]  Dommety, G., "Key and Sequence Number Extensions to GRE",
              RFC 2890, September 2000.

   [RFC5586]  Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
              Associated Channel", RFC 5586, June 2009.





Srinivas & Frost         Expires March 30, 2012                 [Page 5]

Internet-Draft       GRE Generic Associated Channel       September 2011


5.2.  Informative References

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, June 2010.

   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks", RFC 6374, September 2011.


Authors' Addresses

   Prashant Srinivas (editor)
   Cisco Systems
   1414 Massachusetts Ave
   Boxborough, MA  01719
   USA

   Email: prasrini@cisco.com


   Dan Frost (editor)
   Cisco Systems

   Email: danfrost@cisco.com



























Srinivas & Frost         Expires March 30, 2012                 [Page 6]