Subject: Support of Null Service (RFC 2997) for RSVP-TE

From: S Leung <[email-masked]>
Date: Fri, 12 Apr 2002 10:59:50 -0700 (PDT)

Hi,

I have a few questions regarding the Null Service
described in RFC 3209. Would very much appreciate if
you can share some lights with me.

1) According to RFC 2997, Section 2 (Operational
   Overview):  Network nodes receiving these PATH
   messages interpret the service type to indicate 
   that the application is requesting no specific
   service type or quantifiable resources.

   However in Section 3.1 (ADSPEC Generation) and 3.2
   (RSVP SENDER_TSPEC object), there describe that
   network nodes may include guaranteed or controlled
   load services in the ADSPEC and the TSPEC.

Questions: 
a) What does a NULL service with guaranteed or
   controlled load services represent?
b) How should the network node behave?

2) I searched through the Cisco website and found that
   the Catalyst 6000 product seems to support the RSVP
   Null Service.

Question:
a) Any other Cisco product support the RSVP Null
   Service?  If yes, which software release?
b) Assuming I have such a product in my lab, can
   anyone suggest how to test Null Service in the
   lab?  Any link I can read?  Is a separate PDP/PEP 
   device required?
   
3) I searched through the Juniper website but didn't
   seem to find any reference to RFC 2997 nor Null 
   Service.

Questions:
1) Anyone knows if JUNOS 5.3 supports the Null Service
   or not?

Thanks very much for your time in advance.

Regards,
S. Leung
   
--- S Leung <[email-masked]> wrote:
> Hi,
> 
> I have a question regarding RFC 3209.  One
> difference
> between RFC 3209 and the RSVP-TE draft-07 was the
> introduction of the Null Service (RFC 2997), which
> replaced the CoS Service.
> 
> Anyone knows if any vendor out there implements the
> Null Service for RSVP-TE?  If yes, which vendor and
> which software version?
> 
> Thanks very much for your answers in advance.
> 
> S. Leung

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

---

From: David Charlap <[email-masked]>
Date: Fri, 12 Apr 2002 18:37:50 -0400

S Leung wrote:
> 
> I have a few questions regarding the Null Service described in RFC
> 3209. Would very much appreciate if you can share some lights with
> me.

I can tell you what I'm doing.  If it's incorrect, hopefully one of the
authors can correct me.

> 1) According to RFC 2997, Section 2 (Operational Overview):
>    Network nodes receiving these PATH messages interpret the
>    service type to indicate that the application is requesting no
>    specific service type or quantifiable resources.

Correct.  Null service means best-effort (in the absence of other QoS
information, like DiffServ data, of course.)

>    However in Section 3.1 (ADSPEC Generation) and 3.2 (RSVP
>    SENDER_TSPEC object), there describe that network nodes may
>    include guaranteed or controlled load services in the ADSPEC and
>    the TSPEC.

First off, guaranteed service and controlled load service are never
specified in the TSPEC.  There are two different varieties of TSpec that
are valid - the "default/general parameters" which specify values
appropriate for all IntServ types, and Null service, which is only
applicable for Null service reservations.

The ADSPEC's design allows it to contain service fragments with multiple
services specified.  The egress node, upon receiving an ADSPEC is
supposed to select a service from among those present.  It is legal to
pick any represented service.

> b) How should the network node behave?

My assumptions are:

- If the TSpec indicates Null service, then a Null service
  reservation is made, regardless of the Adspec.  I see this as
  mandatory, because the Null service TSpec doesn't have enough
  information for making a CL or GS reservation.

- If the TSpec indicates general/default parameters, then the
  reservation should be chosen from the services that are present in
  the Adspec.  My rule of thumb is to prefer the more strict verison:

	- If there is a GS service, make a GS reservation
	- If there is no GS, but there is CL, make a CL reservation
	- If there is no GS and no CL, but there is Null service,
	  make a Null service best-effort reservation.

- There is still the issue of what to do if there is a general/default
  parameter TSpec and the Adspec contains no supported services (or
  no services at all), or if the Adspec is missing.  While this is
  technically malformed, I don't reject it, because there are some
  vendors who generate Path messages like this.  Instead, I put a
  configurable option on the switch, to allow this to be interpreted
  as GS, CL or best-effort.  This will allow for some degree of
  interoperability.

>    the Catalyst 6000 product seems to support the RSVP

OK.  Not everybody supports this yet.  In version -07 of the RSVP-TE
draft, there was a "class of service" version of the TSpec and Flowspec
objects, which was preferred for signaling best-effort.  This object was
removed from version -08, and is not present in the RFC.  Null service
should be used instead.  Not all products have been upgraded, however.

This means that backwards compatibility with the other methods of
requesting best-effort service must be implemented as well.  The other
two methods are:

- The class-of-service TSpec/Flowspec objects.  (RSVP-TE drafts -01
  through -07)

- A controlled-load request with the bandwidth parameters of the TSpec
  (r and p) set to zero (which means "don't care" in IntServ objects).

In order to interoperate with those routers that don't yet support Null
service, a transit router must recognize and handle all three formats. 
An egress router must respond with the Flowspec that matches the
incoming Path message.  An ingress router must be able to make a
best-effort request using all three formats.  (Probably via a
configurable option.)

>    Service?  If yes, which software release?

You should ask about this on a Cisco mailing list.

This list is meant for those people working on developing MPLS
protocols, not for information about specific commercial products.

>    lab?  Any link I can read?  Is a separate PDP/PEP

Can't help you here.  I don't think any current RSVP test equipment yet
recognizes this object.  You may have to roll your own.

> 1) Anyone knows if JUNOS 5.3 supports the Null Service

You should ask about this on a Juniper mailing list.

-- David