Re: GRE Extensions (Modified)
Raymond Hsu <rhsu@qualcomm.com> Fri, 17 March 2000 17:56 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18717; Fri, 17 Mar 2000 09:56:53 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07301 Fri, 17 Mar 2000 11:11:34 -0500 (EST)
Message-Id: <200003171611.IAA17317@jittlov.qualcomm.com>
X-Sender: rhsu@fezik.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1
Date: Fri, 17 Mar 2000 08:12:08 -0800
To: Gopal Dommety <gdommety@cisco.com>, tsgp@3gpp2.org
From: Raymond Hsu <rhsu@qualcomm.com>
Subject: Re: GRE Extensions (Modified)
Cc: udlr@sophia.inria.fr, msdp@antc.uoregon.edu, ipsec@lists.tislabs.com, MOBILE-IP@standards.nortelnetworks.com, l2tp@ipsec.org, tsgp@3gpp2.org, tsga@3gpp2.org
In-Reply-To: <LYR1158584-196913-2000.03.17-00.58.48--rhsu#qualcomm.com@3 gpp2.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi Gopal: In TR-45.6's R-P interface (aka A10 interface), we may use the first option in the direction from the PDSN to the PCF. In this direction, we've identified scenarios where some mobiles require in-sequence delivery and some don't. Since each mobile is identified by the Key field over the R-P interface, we need option 1. However, in the direction from the PCF to the PDSN, we don't have a strong requirement per mobile basis; thus, option 2 is adequate. Therefore, my recommendation is that both options should be allowed in the GRE draft. Regards, Raymond Hsu At 01:06 AM 3/17/00 -0800, Gopal Dommety wrote: >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 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 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: gdommety@cisco.com > >Dommety > > > > > >Thank You. >Regards, >Gopal >--------------------------------------------------------------------------- ---------------------------------- > >Gopal Dommety >408 525 1404 >gdommety@cisco.com >Cisco Systems, San Jose, CA, 95051 > >--- >You are currently subscribed to tsgp as: rhsu@qualcomm.com >
- GRE Extensions (Modified) Gopal Dommety
- Re: GRE Extensions (Modified) Raymond Hsu
- GRE Extensions (Modified) Pete McCann
- Re: GRE Extensions (Modified) Gopal Dommety
- Re: GRE Extensions (Modified) Rene Tio