The MPLS WG Archive

[Puneet Agarwal <puneet@pluris.com>]

Shahram,

Please see my comments below.

>-----Original Message-----
>From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
>Sent: Monday, June 26, 2000 11:42 AM
>To: 'Puneet Agarwal'; 'mpls@uu.net'
>Subject: RE: draft-ietf-mpls-diff-ext-05.txt comments
>
>
>Puneet,
>
>Please see my comments:
>
>>-----Original Message-----
>>From: Puneet Agarwal [mailto:puneet@pluris.com]
>>Sent: Friday, June 23, 2000 8:38 PM
>>To: 'mpls@uu.net'
>>Subject: draft-ietf-mpls-diff-ext-05.txt comments
>>
>>
>>1) The draft needs to detail the usage of hierarchical tunnel (HT)
>>especially
>>in the case of PHP. 
>>
>>For PHP and HT to work for diffserv/MPLS the Penultimate LSR 
>>needs to know
>>the PHB -> EXP
>>mapping of the underlying encapsulated tunnels. Moreover, if a LSP is
>>carrying
>>multiple LSPs with different PHB-> EXP mapping, the 
>>penultimate LSR and even
>>the egress LSR (in case of no PHP) would need to determine 
>>(after Pop), the
>>type of the underlying LSP.
>>
>>Another example to illustrate this complexity:
>>Consider the case when a L-LSP is sent over a prior 
>>established E-LSP. the
>>Penultimate LSR for the E-LSP has no knowledge of tunnels that are
>>hierarchically going through it. Hence when it does the 
>>penultimate POP, it
>>has no knowledge about the PHB->EXP encoding for the underlying L-LSP.
>>In order to do this correctly, one would need to maintain 
>>additional state
>>associated with the outer E-LSP in order to do the correct 
>>PHB-> EXP map for
>>the encapsulated L-LSP.
>
>Not necessarily. This restriction applies only to Uniform 
>model. In case of
>Pipe model, the PHP does not need to know anything about lower 
>LSP, it just
>pops and forwards the packet without modifying the lower label.
>
>The case of Uniform model is already mentioned in section 2.6.6:
>
>"- when the multiple pop operations are performed by the 
>Penultimate LSR,
>note that to perform Encoding of Diff-Serv       Information, the
>Penultimate LSR needs to be aware of the "Set       of PHB-->Encaps
>mappings" for the label corresponding to the      exposed 
>header after all
>the pop operations (or the PHB-->DSCP       mapping). Methods 
>for providing
>this mapping awareness are       outside the scope of this 
>specification."
>
>And section 2.6.3:
>
>"Note that to do so, the Penultimate LSR needs to be aware of 
>the       "Set
>of PHB-->Encaps mappings" for the label corresponding to       
>the exposed
>header (or the PHB-->DSCP mapping). Methods for       
>providing this mapping
>awareness are outside the scope of this       specification."
>
>The type of LSP is implicit in the PHB -> Encaps mapping. And 
>the Egress LSR
>must know the mapping regardless of the type of the LSP.
>

The problem (as you stated) arises at the Penultimate LSR in the Uniform
model. If "Methods for providing this mapping awareness are outside the
scope of this specification", then you really have 2 choices for deployment:
(a) Invent your own protocol to signal the PHB-> EXP information from the
egress LSR to Penultimate LSR for each encapsulated LSP carried in the outer
LSP. The Penultimate LSR would still need to look at the encapsulted LSP to
figure out which PHB->EXP mapping to apply.
OR 
(b) Require that every encapsulated LSP have the same PHB-> EXP mapping as
the top LSP (being PHPed). This also implies that you cannot have E-LSPs
encapsulated in L-LSPs and vica-versa.

It would be nice to add this clarification to the draft (could be in an
appendix).
 

>
>2) pg 21 - In the Pipe Model, when performing multiple push 
>>operations, the
>>LSR may need to be able to encode different PHB->EXP markings for each
>>pushed
>>label in the stack
>
>This is also explained in Section 2.6.4:
>
>"the LSP Ingress, when performing the push operation, encodes 
>the       LSP
>Diff-Serv information in the label entry that is pushed       
>("outer label
>entry") and encodes the Tunneled Diff-Serv       Information in the
>encapsulated header (IP header or swapped      label entry)."
>
>And Section 2.6.6:
>
>"LSRs at different levels of LSPs are expected to operate in 
>the same or in
>different Tunneling Models."
>
>"For support of M levels of push in the Pipe Model:
> - when performing multiple push operations, the LSR:
>      o encodes Diff-Serv Information corresponding to the
>        Outgoing PHB in the transmitted label entry corresponding
>        to the LAST pushed label (ie the label pushed in the outer
>        label entry).
>      o encodes Diff-Serv Information corresponding to the
>Incoming PHB in the encapsulated header (swapped label
>        entry or IP header) as well as in the label entries for
>        all the pushed labels (except the last pushed label)."
>
>Which basically says that the LSR doing the PUSH operation 
>will encode each
>level of push according to its type, and the details of each type is
>described in E-LSP and L-LSP sections. 
>
I just wanted the draft to highlight that potentially the ingress LSR would
need to  encode a *different* PHB-> EXP mapping for *each* encapsulated
header. It would make it clear to hw designers the hw hooks they need to
implement in order to support multiple push operations. As written in the
current draft, it is very easy to miss this fact.

Thanks.

-Puneet