Internet DRAFT - draft-cai-rsvp-unknown-objects
draft-cai-rsvp-unknown-objects
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 classes such that
transit routers will have the ability to forward the messages with
unknown objects in a timely fashion.
draft-cai-rsvp-unknown-objects-00.txt ^L[Page 1]
Internet Draft draft-cai-rsvp-unknown-objects-00.txt October 2001
1. Introduction
RSVP [RSVP, Section 3.10] has defined a set of rules for
implementations to deal with objects that have unknown C-class.
Specifically, for unknown objects whose C-class encoding is 11bbbbbb,
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 node will save the object, and only forward the
message in the next refresh cycle. However, this may not be
acceptable for certain applications, where fast message delivery is
desired.
2. RSVP Extensions
The goal, then, is to provide a mechanism whereby routers can forward
RSVP refresh messages immediately, when the messages contain some
unknown objects. This document defines a new unknown class for this
purpose.
The new extension is based on the existing encoding for Class-Num =
11bbbbbb [RSVP]: when routers receive a RSVP message that have this
type of object, they should ignore the object but forward it in all
messages resulting from this message.
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) //
| |
+-------------+-------------+-------------+-------------+
Currently, the high-order two bits of the Class-Num is used to
determine what action a router should take if it does not recognize
draft-cai-rsvp-unknown-objects-00.txt ^L[Page 2]
Internet Draft draft-cai-rsvp-unknown-objects-00.txt October 2001
the Class-Num of an object.
We propose the following:
- Class-Num = 110bbbbb
The node should follow the rules defined in RSVP for
Class-Num = 11bbbbbb.
- Class-Num = 111bbbbb
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.
2.2. Rules
The following more detailed rules hold for unknown-class objects with
a Class-Num of the form 111bbbbb:
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 the objects are new or different, the
associated 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.
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.
draft-cai-rsvp-unknown-objects-00.txt ^L[Page 3]
Internet Draft draft-cai-rsvp-unknown-objects-00.txt October 2001
2.3. Impact on Other Applications
Currently, no known implementation has used the object classes that
are within the range of 111bbbbb.
3. 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.
4. Acknowledgments
We thank Der-Hwa Gan and Yakov Rekhter for useful discussion.
5. References
[RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP)
-- version 1 functional specification," RFC2205.
6. Author Information
Ting Cai
Terabeam Networks
14833 NE 87th St.
Redmond, WA, USA
mmail: Ting.Cai@terabeam.com
phone: (206) 255-6220
Ping Pan
Juniper Networks
1194 N.Mathilda Ave
Sunnyvale, CA 94089
e-mail: pingpan@juniper.net
phone: (408)-745-3704
draft-cai-rsvp-unknown-objects-00.txt ^L[Page 4]
Internet Draft draft-cai-rsvp-unknown-objects-00.txt October 2001
draft-cai-rsvp-unknown-objects-00.txt ^L[Page 5]
