Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Key and Sequence Number Extensions to GRE (RFC2890)

IP.com Disclosure Number: IPCOM000005009D
Original Publication Date: 2000-Sep-01
Included in the Prior Art Database: 2001-Jul-13
Document File: 8 page(s) / 15K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

G. Dommety: AUTHOR

Abstract

GRE (Generic Routing Encapsulation) specifies a protocol for encapsulation of an arbitrary protocol over another arbitrary network layer protocol. This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header [1].

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 23% of the total text.

Network Working Group G. Dommety Request for Comments: 2890 Cisco Systems Category: Standards Track September 2000

Key and Sequence Number Extensions to GRE

Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

GRE (Generic Routing Encapsulation) specifies a protocol for encapsulation of an arbitrary protocol over another arbitrary network layer protocol. This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header [1].

1. Introduction

The current specification of Generic Routing Encapsulation [1] specifies a protocol for encapsulation of an arbitrary 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 intended to be used for identifying an individual traffic flow within a tunnel. The Sequence Number field is used to maintain sequence of packets within the 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.

Dommety Standards Track [Page 1]

RFC 2890 Key and Sequence Number Extensions to GRE September 2000

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