Subject: RE: Question on RSVP LSP Tunnel Spec

From: K Arvind <[email-masked]>
Date: Thu, 26 Aug 1999 12:31:51 -0400

Lou,

>Yes.  That is the intent of this object.  It is useful when the CoS values
>have local significance to the LSRs along the LSP.

   Thanks for the clarification. I agree that the proposed SENDER_TSPEC 
object is useful where the intent is to convey CoS values of local 
significance. The rsvp-lsp-tunnels draft does state that the 
Class-of-Service should be used "when resources do not have to be allocated 
to the LSP".

>There are already drafts that cover the case of when you want to signal 
the
>CoS (actually DS/PHS) values that are going to be sent over an LSP that is
>setup with an int-serv style allocation.

   I-D "draft-lefaucheur-mpls-diff-ppp-00.txt" (which I presume is one of 
the drafts you have in mind) specifies a new RSVP object (DIFFSERV_PHS) 
defined within the "Class of Service" class to carry PHS information. 
According to this draft:

	"As described in [MPLS_RSVP], bandwidth information may also be signaled 
at LSP establishment time, for the
	purpose of Traffic Engineering, using the SENDER_TSPEC object (in the Path 
message) and the FLOWSPEC Object
	(in the Resv message)"

  I interpret this to mean that bandwidth information is conveyed using 
IntServ SENDER_TSPEC and FLOWSPEC objects. If this interpretation is 
correct, I still have questions about how the DIFFSERV_PHS object fits 
within an RSVP PDU.

The lefaucheur-mpls-ppp draft states the following:

	"This (DIFFSERV_PHS) object may be carried in a PATH message that contains 
the LABEL_REQUEST object to
	 indicate the PHS for which a label is required. The object may also be 
carried in a RESV message that contains a LABEL
	object indicating the PHS for which the label is to be used"

However, it does not specify how this object is carried within a PATH/RESV 
message.

(1) Is the PATH/RESV message format extended to accommodate objects of the 
"Class of Service" class (DIFFSERV_PHS is defined within this class)? If 
so,  bandwidth information can be conveyed using regular IntServ 
SENDER_TSPEC/FLOWSPEC objects. In this case,  is the new format (and any 
implications for backward compatibility/interoperability) specified 
anywhere?

(2) Will a new object (of class SENDER_TSPEC/FLOWSPEC) be defined that 
includes the DIFFSERV_PHS object? If so, will this object include bandwidth 
information (IntServ token bucket spec) also? If not, how will bandwidth 
information be conveyed (do we have to use 2 different 
SENDER_TSPEC/FLOWSPEC objects in the same PDU? does RSVP allow that?). Is 
this new object specified anywhere? ASIDE: Isn't it confusing to have both 
a "Class of Service SENDER_TSPEC" (defined in the rsvp-lsp-tunnel draft) 
and a different yet-to-be-named SENDER_TSPEC that includes an object of 
class "Class of Service" (DIFFSERV_PHS object)? Does the terminology need 
some reworking?

(3) Some other means within the constraints of RSVP? If so, is this 
identified somewhere?

   I would appreciate any clarification on this. Thank you.

Regards,
Arvind.

K. Arvind, Ph.D.
TENOR Networks, Inc.
50, Nagog Park, Acton, MA 01720
W: 978-264-4900 x124
F: 978-264-0671
E: mailto:[email-masked]
U: http://www.tenornetworks.com

-----Original Message-----
From:	Lou Berger [SMTP:[email-masked]]
Sent:	Thursday, August 26, 1999 10:53 AM
To:	[email-masked]
Cc:	'Lou Berger'; [email-masked]'; [email-masked]'; 
[email-masked]'
Subject:	RE: Question on RSVP LSP Tunnel Spec

At 10:44 AM 8/26/99 -0400, K Arvind wrote:
>Lou,
>
>Doesn't the proposed Class-of-Service SENDER_TSPEC object take away the
>ability for the tunnel head end node to convey traffic rate information
>(e.g., token bucket spec) to the nodes along the tunnel? This information
>would be necessary where bandwidth resources are reserved for LSP tunnels
>on the basis of the characteristics of traffic carried on the tunnels.

Yes.  That is the intent of this object.  It is useful when the CoS values
have local significance to the LSRs along the LSP.

Think of 802.1p and q, where, like q, this is providing the place to
transport the cos values but does not define what the values mean.

>
>I think we should convey CoS information through other means, while
>retaining the IntServ SENDER_TSPEC for conveying traffic rate info. There
>are 6 unused bits in the Flags field of the SESSION_ATTRIBUTE. We could 
use
>three of these bits for conveying CoS information.

There are already drafts that cover the case of when you want to signal the
CoS (actually DS/PHS) values that are going to be sent over an LSP that is
setup with an int-serv style allocation.

Lou

>
>Regards,
>Arvind.
>
>
>K. Arvind, Ph.D.
>TENOR Networks, Inc.
>50, Nagog Park, Acton, MA 01720
>W: 978-264-4900 x124
>F: 978-264-0671
>E: mailto:[email-masked]
>U: http://www.tenornetworks.com
>
>
>
>
>-----Original Message-----
>From:	Lou Berger [SMTP:[email-masked]]
>Sent:	Wednesday, August 25, 1999 10:19 AM
>To:	Geping Chen
>Cc:	[email-masked]
>Subject:	Re: Question on RSVP LSP Tunnel Spec
>
>
>At 06:07 PM 8/9/99 -0400, Geping Chen wrote:
>>I have a question regarding the new FLOWSPEC object for CoS
>>service.
>>
>>Does this mean the SENDER_TSPEC and ADSPEC object also
>>need to have a new type of C-Type for CoS service?
>>
>>Thanks,
>>
>>Geping
>
>Geping,
>	[email-masked] pointed out the omission of the tspec a while back.
>Here's what I've asked George to put in on the next rev of the draft:
>
>Old text:
>
>   The format of the Class-of-Service FLOWSPEC object is:
>
>    Class-of-Service FLOWSPEC object: Class = 9, C-Type = 3 (TBA)
>
>New text:
>
>   The same format is used both for SENDER_TSPEC object and
>   FLOWSPEC objects.  The formats are:
>
>    Class-of-Service SENDER_TSPEC object: Class = 12, C-Type = 3 (TBA)
>
>    Class-of-Service FLOWSPEC object: Class = 9, C-Type = 3 (TBA)
>
>The is no Adspec associated with Class-of-Service.  Either no Adspec is
>included or an int-serv adspec with just the Default General
>Characterization Parameters can be used.
>
>Lou
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 26 Aug 1999 12:49:09 -0400

Arvind,

Glad to hear things are clear on the CoS object.  

In terms of the other draft, and draft-ietf-mpls-diff-ext-01.txt, I suggest
you as ask the authors.  My reading was that the object was sufficiently
defined, but it's use was not.  I assumed that the authors meant:
	For path messages:
	<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC> 
                                    [ <ADSPEC> ] [<DIFFSERV_PHS> ...]
	For resv:
       <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
                               [<DIFFSERV_PHS> ...] [ <RECORD_ROUTE> ]

	and

       <SE filter spec> ::=     <FILTER_SPEC> <LABEL> [<DIFFSERV_PHS> ...]
				[ <RECORD_ROUTE> ]

Whatever their intentions, I agree it should be explicit in the drafts.  It
would also be nice to have the object defiend in a single draft.

Lou