[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MOBILE-IP] New GRE Draft Extensions
- To: gre@ops.ietf.org
- Subject: Re: [MOBILE-IP] New GRE Draft Extensions
- From: Gopal Dommety <gdommety@cisco.com>
- Date: Mon, 13 Mar 2000 00:17:08 -0800
- Delivery-date: Mon, 13 Mar 2000 00:04:52 -0800
- Envelope-to: gre-data@psg.com
Hello Rene:
At 11:08 AM 10/03/00 -0800, Rene Tio wrote:
>On Fri, Mar 10, 2000 at 11:25:06AM -0600, Ajoy Singh wrote:
>> Hello Gopal,
>>
>> Here is couple of questions i have regarding the attached GRE draft. I
>> have not participated in previous discussion of GRE, so i am not aware of
>> any decision made by IESG regarding this respect.
>
>I do not know if the IESG figures into this since GRE is informational.
>However I would like to know the reason behind the updates because
>draft-meyer + draft-dommety looks pretty close to RFC 1701. The changes
>appear to be the semantics of the key field, which was somewhat semantic
>free before since its use as an authenticator was always suspect, and the
>split sequence number field. What's the use of deprecating some fields in
>one draft and extending it with the same deprecated fields in another draft?
This draft is supposed to be an addendum to draft-meyers to include in pirticular
the Key and Sequence number fields. It best if we retain as far as possible
the same format as RFC1701 and specify the semantics that most people
agree on.
>
>> 1. What is the Value of Version number field of proposed GRE header ? Is
>> it 0 or something else ? Does it mean that all existing GRE
>> implementations need to change to support this header format to be
>> standard compliant?
>
>There is no change between draft-meyer-gre-update-03.txt and RFC 1701. The
>version field remains 0.
>
>> I was hoping that we can use different version number to support the new
>> extensions and that way we do not require to change existing deployment of
>> GRE. This way any network element can discard right away the GRE packets
>> which it does not support ?
>
>Your point is well-taken. Since the sequence number field is now split, RFC
>1701 GRE will not understand draft-dommety GRE. A new version number may be
>required. This is in contrast to draft-meyer, which is interoperable with
>RFC 1701.
Okay. Will update the draft to use all the four bytes for the Tx sequence number (my original rational
was that since this is ver 0 GRE and defining the semantics different from GRE as in PPTP was acceptable).
Other than PPTP and RP (draft-ietf-mobile-3gwireless), what are the other protocols that use sequence no of GRE?
>
>> 2. In GRE header format you have specified RX Sequence number which seems
>> to me same as ack sequence number of PPTP GRE. Why we need similar thing
>> represented in two different way in two different standards ?
>
>Neither of them are "standards". And not everyone uses GRE for PPTP.
>
>R.
>
>> thanks,
>> ajoy
>>
>> Gopal Dommety wrote:
>>
>> > Hello:
>> >
>> > I am attaching the GRE addendum/extensions. As you go through the
>> > draft at places identified by # there are request for comments. I have
>> > split the sequence no into two subfeilds (the other option is to define an
>> > acknowledgement like PPTP WHEN such a need it felt).
>> >
>> > Please send your comments to gre@ops.ietf.org mailing list. you can
>> > subscribe to this mailing list by sending an email to
>> > request-gre@ops.ietf.org
>> >
>> > Thanks
>> > Gopal
>> >
>> > Network Working Group Gopal Dommety
>> > INTERNET DRAFT cisco Systems
>> > March 2000
>> >
>> > Expires October 2000
>> >
>> > Key and Sequence Number Extensions to GRE
>> > draft-dommety-gre-ext-00.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) |
>> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > | Rx Sequence Number (Optional)| Tx 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 divided into two sub-fields (Tx and
>> > Rx sequence number). These subfields are inserted by the encapsulator
>> > when Sequence Number Present Bit is set . Tx 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 Tx 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.
>> >
>> > The Tx sequence number value ranges from 1 to 65535. The first
>> > datagram is sent with a Tx sequence number of 1. The Tx sequence
>> > number is thus a free running counter represented modulo 65536,
>> > with the exception that 1 is used when modulo 65536 results in 0
>> > (i.e., rollover to 1 instead of 0). The Rx Sequence number is set to 0.
>> >
>> > #Q The Rx can be the Tx sequence number of the last successfully decap
>> > pack. And say that how you use this info is implementation
>> > dependent. I am currently saying Rx sequence no
>> > is set to 0. Comments?
>>
>> The only possible way this sequence number can be used to support some type of sliding window protocol either for
>>
>> flow control or retransmission. I belive this does
>>
>> >
>> >
>> > 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 Tx 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 Tx sequence
>> > number of the received packet is lesser than or equal to the Tx
>> > sequence number of last successfully decapsulated
>> > packet. The Tx sequence number of a received message is considered
>> > less than or equal to the last successfully received Tx sequence number
>> > if its value lies in the range of the last received Tx sequence number
>> > and the preceding 32766 values, inclusive. For example, if the last
>> > successfully received Tx sequence number was 15, then messages with Tx
>> > sequence numbers 1 through 15, as well as 32784 through 65535, would be
>> > considered less than or equal. Such a message would be considered an
>> > out-of-sequence packet and ignored from processing.
>> >
>> > If the received packet is an in-sequence packet, it is successfully
>> > de capsulated. Note that the TX 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.
>> >
>> > #C I have considered trying to have a different starting point for TX
>> > sequence nos during rollover and initial starting point. This would
>> > let a node identify if the other end reset (like agent advertisement
>> > sequence no to identify reboot and normal rollover). This is useful if
>> > we keep turning on and off sequence nos option in a tunnel. Since
>> > there is no security it is easy for others to reset the sequence
>> > also. Comments?
>> >
>> > 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
>>
>
Thank You.
Regards,
Gopal
-------------------------------------------------------------------------------------------------------------
Gopal Dommety
408 525 1404
gdommety@cisco.com
Cisco Systems, San Jose, CA, 95051