Subject: GRE Extensions (Modified)

From: Gopal Dommety <[email-masked]>
Date: Fri, 17 Mar 2000 01:06:27 -0800

Hello:

I have changed the sequence no  to be 4 bytes.  The changes request by
most have been made.

A remining issue is regarding  the behaviour when both sequence no and
the Key are present. There are two options:

1. Have sequence no  per Key.  This will give  better granularity with
   added complexity of implementation.

2. Sequence no for the tunnel irrespective of the Key. 

Let me know your opinion.

Thanks
Gopal

Network Working Group				      Gopal Dommety
INTERNET DRAFT                                        cisco Systems
Category: Standards Track                             March 2000  
Title:  draft-dommety-gre-ext-01.txt                  

Expires October 2000

		Key and Sequence Number Extensions to GRE
		    draft-dommety-gre-ext-01.txt

Status of this Memo

   This document is a submission by the Network Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be submitted
   to the [email-masked] mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and working groups. Note that other groups may also distribute
   working documents as Internet Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.
   
Abstract
   
   This  document describes extensions  by which  two fields,  Key and
Sequence Number, can be optionally carried in the GRE (Generic Routing
Encapsulation) Header  [1]. GRE specifies a  protocol for encapsulation
of an arbitrary network  layer protocol over another arbitrary network
layer  protocol. 

Dommety		                                                  [Page 1]

Internet Draft  Key and Sequence Number Extensions to GRE  February 2000

1. Introduction

   Current specification of Generic Routing Encapsulation [1] specifies
a protocol  for encapsulation of  an arbitrary network  layer protocol
over another arbitrary network layer protocol. This document describes
enhancements  by which  two fields,  Key and  Sequence Number,  can be
optionally carried  in the GRE  Header [1]. The  Key field is  used to
create separate sub-tunnels within  a GRE Tunnel. Sequence Number field
is used to maintain sequence of packets within a GRE Tunnel.

1.1. Specification Language

   The keywords "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 [3].

   In addition, the following words are used to signify the 
   requirements of the specification.  

   Silently discard
              The implementation discards the datagram without
              further processing, and without indicating an error
              to the sender.  The implementation SHOULD provide the
              capability of logging the error, including the contents
              of the discarded datagram, and SHOULD record the event
              in a statistics counter.

2. Extensions to GRE Header

   The GRE packet header[1] has the following format:

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |C|       Reserved0       | Ver |         Protocol Type         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Checksum (optional)      |       Reserved1 (Optional)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The proposed GRE header will have the following format:

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |C| |K|S| Reserved0       | Ver |         Protocol Type         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Checksum (optional)      |       Reserved1 (Optional)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Key (optional)                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Sequence Number (Optional)                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Key Present (bit 2)

      If the Key Present bit is set to 1, then it indicates that the Key
      field is present in the GRE header.  Otherwise, the Key field is
      not present in the GRE header.

      Sequence Number Present (bit 3)

      If the Sequence Number Present bit is set to 1, then it indicates
      that the Sequence Number field is present.  Otherwise, the
      Sequence Number field is not present in the GRE header.

      The  Key and Sequence Present bits are chosen to be  compatible 
      with RFC 1701 [2].
 
2.1. Key Field (4 octets)

     The Key field contains a  four octet number which was inserted by
     the encapsulator. The actual method by which this Key is obtained
     is beyond the scope of this document.  Key field is intended to be
     used for  creating separate sub-tunnels within a  GRE Tunnel and the
     Key field identifies the sub-tunnel. 

2.2. Sequence Number (4 octets)
 
    The Sequence Number field is a  four byte feild and is inserted by
    the  encapsulator when  Sequence Number  Present Bit  is set. The
    Sequence  Number MUST  be used  by the  receiver to  establish the
    order in which packets have been transmitted from the encapsulator
    to the receiver.  The intended use  of the Sequence Field is to
    provide unreliable and in-order  delivery.  If the Key present bit
    (bit 2) is set, the  sequence number is specific to the sub-tunnel
    identified by the Key field. Note that packets without the sequence
     bit set can be sent in between packets with the sequence bit set.

    The  sequence number  value ranges from 1 to  2**32-1. The first 
    datagram is sent with a sequence number of 1. The  sequence 
    number is thus a free running counter represented modulo 2**32, 
    with the exception that 1 is used when modulo 2**32 results in 0 
    (i.e., rollover to 1 instead of 0). 

    When the decapsulator receives an out-of sequence packet it SHOULD
    be silently discarded. Additionally, reordering of out-of sequence
    packets  MAY  be  performed   by  the  decapsulator  for  improved
    performance and  tolerance to reordering in the  network (since the
    state of the stateful compression or encryption is reset by packet
    loss, it  might help the  performance to tolerate some  amount of
    packet reordering in the network by buffering). Exact buffering 
    schemes are outside the scope of  this  document. Note that the  
    sequence number is used to detect
    lost packets and/or restore  the original sequence of packets that
    may have been reordered during transport.

   A packet  is considered an out-of-sequence packet  if the  sequence
   number  of  the  received packet  is  lesser than or equal to  the 
   sequence  number   of last  successfully  decapsulated
   packet. The  sequence number  of a received message is considered
   less than or equal to the last successfully received  sequence number 
   if its value lies in the range of the last received  sequence number 
   and the preceding 65534 values, inclusive. 

    If  the   received  packet  is   an  in-sequence  packet,   it  is
    successfully decapsulated.  Note that  the sequence number is used
    to  detect lost packets  and/or restore  the original  sequence of
    packets  (with  buffering) that  may  have  been reordered  during
    transport.   Use of  the  sequence number  option  should be  used
    appropriately; in particular, it is a good idea a avoid using when
    tunneling  protocols  that  have  higher layer  in-order  delivery
    mechanisms or are tolerant to out-of-order delivery. If only at certain 
    instances the protocol being carried in the GRE tunnel requires
    in-sequence delivery, only the corresponding packets encapsulated 
    in a GRE header can be sent with the sequence bit set. Mechanisims 
    to determine which packets need to be sent in-sequence and the 
    signaling mechanisims are outside the scope of this document.

3. IANA Considerations

4. Acknowledgments

5. References

   [1] Farinacci,  D., Li,  T., Hnaks, S.,  Meyer, D. and  Traina, P.,
   "Generic           Routing           Encapsulation          (GRE),"
   draft-meyer-gre-update-03.txt, January 2000.

   [2]  Hanks, S.,  Li,  T,  Farinacci, D.,  and  P. Traina,  "Generic
   Routing Encapsulation",  RFC 1701, NetSmiths,  Ltd., and cisco Systems, 
   October 1994.

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

Dommety                                                 [Page 4]

Internet Draft   Key and Sequence Number extensions to GRE   February 2000

Author Information

   Gopal Dommety
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   e-mail: [email-masked]

Dommety

Thank You.
Regards,
Gopal
-------------------------------------------------------------------------------------------------------------

Gopal Dommety
408 525 1404 
[email-masked]
Cisco Systems, San Jose, CA, 95051

---

From: Pete McCann <[email-masked]>
Date: Fri, 17 Mar 2000 09:16:36 -0600 (CST)

The sequence number should definitely be per key!  That way we can
tunnel multiple streams, one per key.  Each needs its own sequencing.

-Pete

Gopal Dommety <[email-masked]> (GD) writes:

GD> Hello:
GD> I have changed the sequence no  to be 4 bytes.  The changes request by
GD> most have been made.

GD> A remining issue is regarding  the behaviour when both sequence no and
GD> the Key are present. There are two options:

GD> 1. Have sequence no  per Key.  This will give  better granularity with
GD>    added complexity of implementation.

GD> 2. Sequence no for the tunnel irrespective of the Key.