The MPLS WG Archive

[Francois Le Faucheur <flefauch@cisco.com>]

Alia,

At 17:49 26/06/2000 -0500, Alia Atlas wrote:
>Hi,
>
>I have two comments on the draft.  I would like to see the draft support
>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
>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 
> 


_________________________________________________________________
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:          	flefauch@cisco.com
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________