Subject: Re: [MOBILE-IP] GRE Extensions (Modified)

From: Raymond Hsu <[email-masked]>
Date: Fri, 17 Mar 2000 08:12:08 -0800

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 [email-masked] 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: [email-masked]
>
>Dommety
>
>
>
>
>
>Thank You.
>Regards,
>Gopal
>---------------------------------------------------------------------------
----------------------------------
>
>Gopal Dommety
>408 525 1404
>[email-masked]
>Cisco Systems, San Jose, CA, 95051
>
>---
>You are currently subscribed to tsgp as: [email-masked]
>

---

From: Rene Tio <[email-masked]>
Date: Fri, 17 Mar 2000 11:10:50 -0800

> my recommendation is that both options should be allowed in the GRE draft.

I think if we plan the most limiting case (option 1, which we have at
least a few opinions is necessary) and allow for the not-so-limiting, both
cases will be covered.

IMHO the C, K, and S fields are a request for the other end to check, not a
requirement that the other end should send, i.e., if you configure a tunnel
to have checksums, you send checksums but don't require the other end to
send checksums (it's part of the "be liberal in what you receive" paradigm).
Thus in the PCF to PDSN direction you just don't configure sequence numbers
and everything Should Just Work.

Cheers,
Rene

ps/ Funny how the PPTP draft is vague on this as well, or at least my quick
    glance did not find any statement on this matter.  I don't think it
    would work if you didn't have a sequence number per key though, as one
    missed packet may cause you to turf packets across many PPP sessions.

---

From: Gopal Dommety <[email-masked]>
Date: Fri, 17 Mar 2000 12:49:00 -0800

Ray and Pete:

Thanks. I agree with both of you. That is why the current version has this description.
There was comment on the performance and that it might not be good to couple Key and sequence.
 So, I wanted to get opinion.

Ray, even in the PCF to PDSN direction, we don't absolutely need it. We can do with option 2, but the
performance may effected.  If you want to do some sort of buffering and reodering, not having a sequence no
will hurt performance (basically the sequence no will not have per session significance).

In the draft, we have option 1 as of now. Unless there is a major objections let us leave it as it is.

thanks
Gopal

>>   The GRE packet header[1] has the following format:
Thank You.
Regards,
Gopal
-------------------------------------------------------------------------------------------------------------

Gopal Dommety
408 525 1404
[email-masked]

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 22 Mar 2000 11:21:36 +0900

Hello Gopal,
  In your anchor handoff draft RFC, you propose to use zone IDs to be
advertised
by FAs so that MNs can detect the change of the zone.
  In the draft RFC on regional registration (reg-tunnel-02), FAs should
include their NAIs
in the agent advertisements using FA NAI extension.
  While NAI has a well defined structure, and zone ID does not seem to
be well defined
however as a concept the zone ID could be better than NAI which was
defined to identify persons.
  What do you think?

Regards,

--behcet

--
Behcet Sarikaya
Computer Communications Lab.
The University of Aizu
Tsuruga, Ikki-machi, Aizu-wakamatsu City
Fukushima, 965-8580 Japan
Tel. +81-242-37-2559 Fax. +81-242-37-2742
Home page:  http://www.u-aizu.ac.jp/~sarikaya/
email: [email-masked]