Subject: Last Call feedback on MPLS-diffserv

From: Alia Atlas <[email-masked]>
Date: Mon, 26 Jun 2000 17:49:00 -0500

Hi,

I have two comments on the draft.  I would like to see the draft support
signalling of the tunnelling mode; a suggested method is below.  Second, I
would like to clarify supporting bandwidth reservation on E-LSPs.  Towards each
purpose, as described below, I would suggest using a reserved bit.

There are two tunnelling modes in which each LSP could operate.
However, the draft gives no guidelines as to how to determine which
mode a given LSP should use.   I would like to suggest using one of
the reserved bits in the DIFFSERV object for this purpose, as follows:
 
   DIFFSERV object for an E-LSP:

   class = TBD, C_Type = 1  (need to get an official class num from the
   IANA with the form 0bbbbbbb)

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Reserved                                     |T| MAPnb |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            MAP (1)                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    //                               ...                            //
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            MAP (MAPnb)                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Reserved : 27 bits
       This field is reserved. It must be set to zero on transmission
       and must be ignored on receipt.

        T : 1 bit
          Specifies the tunnel mode to be used by the LSP.  If 0, then the
       tunnel mode is Uniform.  If 1, the tunnel mode is Pipe.

   DIFFSERV object for an L-LSP:

   class = TBD, C_Type = 2  (class num is the same as DIFFSERV object
   for E-LSP))

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Reserved             |T|             PSC               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Reserved : 16 bits
       This field is reserved. It must be set to zero on transmission
       and must be ignored on receipt.
        
        T : 1 bit
          Specifies the tunnel mode to be used by the LSP.  If 0, then the
       tunnel mode is Uniform.  If 1, the tunnel mode is Pipe.

Similar bits can be acquired from the reserved for the Diff-Serv TLV.

For RSVP, if a router cannot support the specified tunnelling mode, it would
report a 'Diff-Serv Error' with a value of 5 = "Unsupported Tunnel Mode". 
Similarly, for LDP, a status code of 0x0000001A could be used for  
"Unsupported Tunnel Mode".

I realize that this does not provide flexibility for future tunnel modes, so
more bits could be dedicated to this purpose, as and when deemed appropriate.

I would like to spend a second bit to properly support signalled bandwidth
reservations for E-LSPs.  Currently the draft has an inconsistency.

In Section 1.6, the current draft states:
  "When bandwidth requirements are signaled at establishment of an
   E-LSP, the signaled bandwidth is associated collectively to the
   whole LSP and therefore to the set of transported PSCs. Thus, LSRs
   which use the signaled bandwidth to perform admission control may
   perform admission control over global resources which are shared by
   the set of PSCs (e.g. over the total bandwidth of the link)."

In Section 5.6, the draft further specifies:
  "To establish an E-LSP or an L-LSP with bandwidth reservation, Int-
   Serv's Controlled Load service (or possibly Guaranteed Service) is
   used and the bandwidth is signaled in the SENDER_TSPEC (respectively
   FLOWSPEC) of the path (respectively Resv) message.
   ....
   The above is summarized in the following table:

           Path Message  LSP type
    Service  DIFFSERV
              Object

     GS/CL     No        E-LSP + preconf mapping + bandw reservation
     GS/CL   Yes/E-LSP   E-LSP + signaled mapping + bandw reservation
     GS/CL   Yes/L-LSP   L-LSP + bandw reservation
     COS       No        E-LSP + preconf mapping + no bandw reservation
     COS     Yes/E-LSP   E-LSP + signaled mapping + no band reservation
     COS     Yes/L-LSP   L-LSP + no bandw reservation

   Where:
        - GS stands for Guaranteed Service
        - CL stands for Controlled Load
        - COS stands for COS service"

Thus, if a RESV message contains both a TSpec with GS or CL specified and a
Diffserv object for an E-LSP, bandwidth reservation is the appropriate
behavior.  However, adequate information is not supplied to know how much
additional bandwidth each PHB used by the E-LSP should be provisioned with.

Given that it would be desirable to support bandwidth reservations associated
with E-LSPs, I would propose the following modifications to the Diffserv Object
and Diff-Serv TLV.  
DIFFSERV object for an E-LSP:

   class = TBD, C_Type = 1  (need to get an official class num from the 
   IANA with the form 0bbbbbbb)

     0                   1                   2                   3 
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |B|        Reserved                                   |T| MAPnb | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                            MAP (1)                            | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                                                               | 
    //                               ...                            // 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                            MAP (MAPnb)                        | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Reserved : 26 bits 
       This field is reserved. It must be set to zero on transmission 
       and must be ignored on receipt.

             B : 1 bit 
                This flag indicates whether bandwidth is explicitly specified
per MAP.  
       If it is 0, no bandwidth is explicitly signalled, and the Diffserv
object 
        is not further modified.  If it is 1, then the Diffserv object will 
       contain those bandwidths as described below: 
         
    0                   1                   2                   3 
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |1|        Reserved                                   |T| MAPnb | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                            MAP (1)                            | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                            BW (1)                             | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                                                               | 
    //                               ...                            // 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                            MAP (MAPnb)                        | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                            BW (MAPnb)                         | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      BW : 32 bits 
                  Bandwidth reserved for the above PHBID.  This is specified as
a               standard IEEE floating number.  The units are bytes/sec.

When the Bandwidth flag is set, the rate signalled in the Tspec is ignored. 
Instead, the bandwidths signalled in the Diffserv Object would be used.

I am not certain how to specify this feature with LDP, because I am less
familiar with LDP.  No language in the draft exists to specify how bandwidth
reservation might be done using LDP.  Perhaps someone with greater knowledge of
LDP could take a look and determine whether it makes sense to support this
feature in LDP and how it might be done.

Please let me know what you think.

Thanks,
Alia

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 28 Jun 2000 09:39:46 +0200

Alia,

At 17:49 26/06/2000 -0500, Alia Atlas wrote:
>signalling of the tunnelling mode; 

This is something that has been discussed already. Please see the thread "RE: Hierarchical Tunnel Establishment in RSVP-TE" on the alias. The outcome of the thread was in essence that it was not clear that this would actually be required and that it could be added later if/when such requirement is clarified. Your colleague Curtis proposed updated wording to that effect to which we agreed:
=It may be better if the
=wording in draft-ietf-mpls-diff-ext-05.txt declared the signaling to
=set uniform or pipe on a per LSP basis as out of scope rather than
=precluding it so that a later document can define the signaling if
=there is a need.

Also, I suspect that if we wanted to have full support of the Uniform/Pipe Models through signalling for all cases we might need to do something more (eg see the issue that with uniform & PHP the Penultimate Hop has to be aware of the mappings of encapsulated LSP). 

> Second, I
>would like to clarify supporting bandwidth reservation on E-LSPs.  

What you are discussing below is actually the ability to signal bandwidth on a per-PSC basis within an E-LSP. THis is a potential option which has been discussed at length already since it had been requested by Curtis. 
The bottom line is that the current spec already has quite a number of options and these existing options currently let you (i) "route" together multiple PSCs and signal/reserve bandwidth on an aggregate basis across those PSCs (using E-LSPs), (ii) "route" separately individual PSC and signal/reserve bandwidth on a per-PSC basis (using L-LSPs). Signaling per-PSC bandwidth over E-LSPs woudl allow the ability to "route" multiple PSCs together while signalling/reserving bandwidth on a per-PSC basis. I polled the group on this very topic and the conclusion was that the benefits of this last option did not justify yet another option for the first version of the spec.

Thanks

Francois

>Towards each

_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Office Phone:   	+33 4 92 96 75 64
Home Office Phone:     +33 4 92 94 00 78
Mobile :               +33 6 89 108 159
Vmail:                 +33 1 58 04 62 66
Fax:                   +33 4 92 96 79 08
Email:          	[email-masked]
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________