Subject: Mandatory objects when using RSVP-TE for LSP Tunnels

From: Jean-Bertos Simo <[email-masked]>
Date: Thu, 1 Nov 2001 14:21:13 -0500

In draft-ietf-mpls-rsvp-lsp-tunnels-08.txt, <sender descriptor> and
<LABEL_REQUEST> are mandatory objects in a Path Message. I would like
someone to enlighten me about the following issues:

1) What's the expected behavior of an RSVP-capable router that receives a
Path Message:
-  without a <LABEL_REQUEST> object?
-  without a <sender descriptor> object?
My understanding is that the Path Message can be silently dropped or the
router can return a PathErr Message. However, my preference would go to
dropping the Path Message to reduce traffic load.

2) Are these two objects mandatory in a PathTear Message when dealing with a
LSP_TUNNEL_IPV4_SESSION session object? 

3) If any of these objects is missing in a PathTear Message, what behavior
is expected from a RSVP-capable router?

4) When processing a PathTear Message, do we have to check whether  the
<SENDER_TEMPLATE> or  <SENDER_TSPEC> objects are empty or containing any
data?

5) Can anyone provide me references where I can find mandatory objects of
Teardown, Error and Confirmation messages of RSVP-TE?

Thanks for your help.

Jean-Bertos

---

From: David Charlap <[email-masked]>
Date: Thu, 01 Nov 2001 16:48:54 -0500

Jean-Bertos Simo wrote:
> 
> In draft-ietf-mpls-rsvp-lsp-tunnels-08.txt

Please note that the current draft is version -09.

> , <sender descriptor> and <LABEL_REQUEST> are mandatory objects in
> a Path Message. I would like someone to enlighten me about the
> following issues:
> 
> 1) What's the expected behavior of an RSVP-capable router that
> receives a Path Message:

This menans that the Path message may not be used for LSP setup.  If
your router is capable of using RSVP to signal resource reservations on
unlabeled packets (aka classical RSVP, as defined by RFC 2205), then you
can process the Path message.  If your router only uses RSVP for setting
up LSPs, then a required object is missing - drop the packet.

> -  without a <sender descriptor> object?

If your RSVP implementation is only capable of setting up LSPs, then
mandatory objects are missing - drop the packet.

If your RSVP implementation is capable of classical RSVP operation, then
it should accept the packet.  A missing sender descriptor is legal if a
WF-style reservation is reserved by the egress router, since WF style
does not require identification of the sender.  Note that WF style
reservation is not valid for MPLS.

> My understanding is that the Path Message can be silently dropped or
> the router can return a PathErr Message. However, my preference would
> go to dropping the Path Message to reduce traffic load.

There is no error code defined that you could use in a PathErr for
this.  Therefore, you should not generate a PathErr in this situation.

> 2) Are these two objects mandatory in a PathTear Message when dealing
> with a LSP_TUNNEL_IPV4_SESSION session object?

LABEL_REQUEST is not required for PathTear.  It is not part of the BNF
of RFC-2205 (obviously), and no updated BNF is provided in the RSVP-TE
draft.

Sender decriptors are optional in PathTear, in the same sense as they
are optional in Path messages.  I'm not 100% certain, but it's my
understanding that a sender descriptor is needed when tearing down any
Path that was set up using a sender dscriptor - since it is required to
identify the sender.

> 3) If any of these objects is missing in a PathTear Message, what
> behavior is expected from a RSVP-capable router?

Errors in PathTear messages never result in generation of error-message
packets.  There is no such thing as a PathTearErr message.  If a
required object is missing, the packet is dropped.

> 4) When processing a PathTear Message, do we have to check whether
> the <SENDER_TEMPLATE> or  <SENDER_TSPEC> objects are empty or
> containing any data?

Read RFC 2205.  Section 3.1.5.

TSPEC and ADSPEC are optional and should be ignored in PathTear
messages.

SENDER_TEMPLATE is required to identify the sender.  If it is missing,
then you can't identify which sender in the session is being torn.

> 5) Can anyone provide me references where I can find mandatory
> objects of Teardown, Error and Confirmation messages of RSVP-TE?

RFC 2205.

-- David