Network Working Group                                        Ting Cai
Internet Draft                                             (Terabeam)
Expiration Date: May 2002                                    Ping Pan
Network Working Group                               (Juniper Networks)



     Extending RSVP Object Class Encoding To Handle Unknown Objects

                 draft-cai-rsvp-unknown-objects-00.txt

Status of this Memo

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 its 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 memo describes a new method to encode RSVP object class numbers
such that transit routers will have the ability to forward the messages
with unknown objects in a timely fashion.















draft-cai-rsvp-unknown-objects-01.txt                           ^L[Page 1]

Internet Draft    draft-cai-rsvp-unknown-objects-01.txt    November 2001


. Introduction

   RSVP [RSVP, Section 3.10] has defined a set of rules for
   implementations to deal with objects that have unknown class number.

   Specifically, for unknown objects whose Class-Num octet is 11bbbbbb
   (that is, the two high-order bits are set), the router must not
   reject the message and/or ignore the object. Instead, when one such
   unknown-class object is received in a tear-down or an error message,
   the entire RSVP message must be forwarded immediately.

   If a such unknown-class object is received in a Path or a Resv
   refresh message, the router will save the object, and only forward
   the message in the next refresh cycle. However, this behavior may not
   be acceptable for certain applications, where fast message delivery
   is desired.



. RSVP Extensions

   The goal, then, is to provide a mechanism whereby routers can forward
   RSVP messages immediately, when the messages contain some unknown
   objects.  This document defines a new unknown class number range for
   this purpose.  The new extension is based on the existing encoding
   for Class-Num = 11bbbbbb [RSVP, Section 3.10].


2.1. Syntax

   Every RSVP object consists of a one-word header, with the following
   format:

            0             1              2             3
     +-------------+-------------+-------------+-------------+
     |       Length (bytes)      |  Class-Num  |   C-Type    |
     +-------------+-------------+-------------+-------------+
     |                                                       |
     //                  (Object contents)                   //
     |                                                       |
     +-------------+-------------+-------------+-------------+

   According to RFC2205, the high-order two bits of the Class-Num is
   used to determine what action a router should take if it does not
   recognize the Class-Num of an object. We extend this and propose the
   following:

    - Class-Num = 110bbbbb



draft-cai-rsvp-unknown-objects-01.txt                           ^L[Page 2]

Internet Draft    draft-cai-rsvp-unknown-objects-01.txt    November 2001


      The router should check the object. If the object is new or
      different from the one that has been saved by the router,
      the message MUST be treated as a trigger message, and be
      processed accordingly.

    - Class-Num = 111bbbbb

      The node should follow the rules defined in RSVP for
      Class-Num = 11bbbbbb.



2.2. Detailed Rules

   The following more detailed rules hold for unknown-class objects with
   a Class-Num of the form 110bbbbb:

    1. Such unknown-class objects received in PathTear, ResvTear,
       PathErr, or ResvErr messages should be forwarded immediately
       in the same messages.

    2. When such unknown-class objects received in Path or Resv messages
       at a router, they must be compared with previously saved copies,
       if there are any.  If the objects are new or different,
       the received messages MUST be considered as trigger messages,
       and be forwarded immediately.

    3. When a Resv refresh is generated by merging multiple reservation
       requests, the refresh message should include the union of
       unknown-class objects from the component requests. Only one copy
       of each unique unknown-class object should be included in this
       union. The merged message must be forwarded immediately.

    4. The original order of such unknown-class objects need not be
       retained; however, the message that is forwarded must obey the
       general order requirements for its message type.



2.3. Impact on Other Applications

   Currently, there are a number of known implementations that have been
   using the objects within the range of 110bbbbb, and can benefit from
   our proposal.

   The SESSION_ATTRIBUTE object (Class_Num 207) [RSVP-TE] is used to aid
   the setup of RSVP-TE LSPs, and is optional in Path messages.  It
   carries control information such as local protection flags.  It is



draft-cai-rsvp-unknown-objects-01.txt                           ^L[Page 3]

Internet Draft    draft-cai-rsvp-unknown-objects-01.txt    November 2001


   possible that network operators may need to change a LSP's local
   protection behavior at run-time, for example, set/reset bandwidth-
   protection and node-protection features by changing the corresponding
   bits in the SESSION_ATTRIBUTE object [RSVP-FR].  If there are routers
   in the network that do not support the object, the local protection
   notifications may not take effect for a long time when using the
   existing rules.  With our proposal, notification messages can be
   forwarded immediately on all network nodes.

   Similarly, FAST_REROUTE object (Class_Num 205) [RSVP-FR] is used to
   setup fast reroutable LSPs in the network, and needs to be forwarded
   in a timely fashion.

   Finally, a recent proposal on LSP data plane detection [LSP-PING] can
   benefit from the fast message delivery for RSVP unknown objects
   proposed here as well.



. Security Considerations

   Forwarding objects with unknown class defined in this document helps
   incremental deployment of new objects, however, if not careful, it
   can create too many RSVP control messages to be generated and
   processed at routers.



. Acknowledgments

   We thank Der-Hwa Gan and Yakov Rekhter for useful discussion.



. References

   [RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP)
   -- version 1 functional specification," RFC2205.

   [RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP
   tunnels" Internet Draft.

   [RSVP-FR] P. Pan, et al, "Fast Reroute Techniques in RSVP-TE",
   Internet Draft.

   [LSP-PING] P. Pan, et al, "Detecting Data Plane Liveliness in RSVP-
   TE", Internet Draft.




draft-cai-rsvp-unknown-objects-01.txt                           ^L[Page 4]

Internet Draft    draft-cai-rsvp-unknown-objects-01.txt    November 2001


. Author Information


Ting Cai
Terabeam Networks
 NE 87th St.
Redmond, WA, USA
mmail:  Ting.Cai@terabeam.com
phone:  (206) 255-6220

Ping Pan
Juniper Networks
 N.Mathilda Ave
Sunnyvale, CA 94089
e-mail: pingpan@juniper.net
phone: (408)-745-3704



































draft-cai-rsvp-unknown-objects-01.txt                           ^L[Page 5]