[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
GRE addendum Latest version
- To: gre list <gre@ops.ietf.org>
- Subject: GRE addendum Latest version
- From: Gopal Dommety <gdommety@cisco.com>
- Date: Mon, 10 Apr 2000 11:12:33 -0700
- Delivery-date: Mon, 10 Apr 2000 10:59:46 -0700
- Envelope-to: gre-data@psg.com
Network Working Group Gopal Dommety
INTERNET DRAFT cisco Systems
Category: Standards Track March 2000
Title: draft-dommety-gre-ext-02.txt
Expires October 2000
Key and Sequence Number Extensions to GRE
draft-dommety-gre-ext-02.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 gre@ops.ietf.org 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 March 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. A small
amount of reordering buffer may help in improving performance when
the higher layer employs stateful compression or encryption. Since
the state of the stateful compression or encryption is reset by
packet loss, it might help the performance to tolerate some small
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 2**31-1 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. Acknowledgments
This document is derived from the original ideas of the authors of
RFC 1701. Kent Leung, Mark Townsley, Yingchun Xu, Ajoy Singh and
many others provided useful discussion. The author would like to
thank all the above people.
4. References
[1] Farinacci, D., Li, T., Hnaks, S., Meyer, D. and Traina, P.,
"Generic Routing Encapsulation (GRE)," RFC 2784, March 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 March 2000
Author Information
Gopal Dommety
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
e-mail: gdommety@cisco.com
Dommety
Thank You.
Regards,
Gopal
-------------------------------------------------------------------------------------------------------------
Gopal Dommety
408 525 1404
gdommety@cisco.com
Cisco Systems, San Jose, CA, 95051