Subject: RE: Question on RSVP LSP Tunnel Spec

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 02 Sep 1999 15:41:30 +0200

Lou, Arvind,

At 12:49 26/08/1999 -0400, Lou Berger wrote:
>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> ]
>
>

Good suggestion. I will add this in the next version.

To further clarify the usage of objects, our draft (which focuses
exclusively on Diff-Serv - as opposed to pre-Diff-SErv TOS capabilities)
assumed the following possible combinations for Diff-SErv support:
	- traditional TSpec (ie with bandwidth), no DiffServ_PHS --> this is an
E-LSP with bandwith allocation
	- traditional TSpec (ie with bandwidth), with DiffServ_PHS --> this is an
L-LSP with bandwith allocation
	- "COS TSpec" (no bandwidth) COS=0, no Diff-Serv_PHS --> this is E-LSP
without bandwidth allocation
	- "COS TSpec" (no bandwidth) COS=0, Diff-Serv_PHS --> this is L-LSP
without bandwidth allocation

Depending on the outcome of our open discussion on the need to support
multiple E-LSPs, we may also have to allow signaling of PHS for E-LSPs.
This would result in the following additional combinations:
	- "COS TSpec" (no bandwidth) COS=0,  Diff-Serv_PHS --> this is E-LSP
without bandwidth allocation
	- traditional TSpec (ie with bandwidth) COS=0,  Diff-Serv_PHS --> this is
E-LSP with bandwidth allocation

Now with respect to use of non-zero COS_FlowSpec/TSpec, Lou will
confirm/correct my understanding:
<draft-ietf-mpls-rsvp-lsp-tunnel-02.txt> says:
"The intent is to enable networks to support the  IP  ToS  Octet  as
defined in RFC1349 [7].  It is noted that there is ongoing work within the
IETF to update the use of  the  IP  ToS  Octet. In particular, RFC2474
[8], obsoletes RFC1349.  However at this time the new uses of this field
(now termed the  DS  byte)  are still being defined."
Thus, I understand that use of non-zero value in the COS_FlowSpec/TSpec is
intended to support pre-Diff-Serv TOS capabilities (as opposed to Diff-SErv
capabilities). Therefore, an additional possible combination of object is:
	- "COS TSpec" (no bandwidth) COS=non0, no Diff-Serv_PHS --> this is LSP
offering TOS-based Pre-Diff-SErv service without bandwidth allocation (This
LSP does not offer a Diff-SErv service).

I also understand that the following combination would NOT be allowed:
	- "COS TSpec" (no bandwidth) COS=non0, Diff-Serv_PHS --> since the
non-zero COS object would indicate pre-Diff-SErv TOS-based service while
the Diff-Serv_PHS would indicate Diff-Serv service.

Do we agree on the above?

Cheers

Francois

>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
>
>At 12:31 PM 8/26/99 -0400, K Arvind wrote:
>>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
>>>
>>
> 

_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Phone:  +33 4 92 96 75 64
Mobile : +33 6 07 78 69 67
Vmail:   +33 1 69 18 62 66
Fax:      +33 4 92 96 79 08
Email: [email-masked]
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________

---

From: Lou Berger <[email-masked]>
Date: Thu, 02 Sep 1999 16:03:16 -0400

see below...

>LSP does not offer a Diff-SErv service).

Agreed.

>the Diff-Serv_PHS would indicate Diff-Serv service.

I think it should be allowed.  While this case is less likely to be used, I
don't see a good reason to preclude its use by a provider.

Lou

>Do we agree on the above?
[rest deleted]