[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GRE Extensions (Modified)
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
>
Follow-Ups: