Re: [mpls] Association of PSC messages to a protection path

[venkatesan mahalingam <[e-mail]>]

Hi,
Can protection switching guys please answer the below query?

Thanks,
Venkat.

On Thu, Aug 5, 2010 at 1:05 PM, venkatesan mahalingam
<[e-mail]>wrote:

>  Hi,
>
> Please clarify the below query regarding *how to associate the PSC message
> with a protection path.*
>
>
>
> Below are the details.
>
>
>
> Format of the PSC control message is as follows:
>
>
>
> 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
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |0 0 0 1|Version|  Reserved     |   Channel Type = MPLS-TP PSC  |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                          ACH TLV Header                       |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        ~                         Optional TLVs                         ~
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |Ver|Request|PT |R|  Reserved   |     FPath     |     Path      |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Figure 2: Format of PSC packet with a G-ACh header
> (draft-ietf-mpls-tp-linear-protection-02)
>
>
>
> *Transmission of PSC control packets:*
>
> The PSC packet will be encapsulated with the MPLS label and next hop mac
> and will be sent over the out going interface related to the protection
> path.
>
>
>
> *Reception of PSC control packets:*
>
> The PSC control packets will be ‘label switched’ at the intermediate LSRs
> (based on the protection LSP’s label) and thus will reach the LER.
>
>
>
> *The questions are:*
>
> *1)       **Associating PSC with protection path based on the label stack:
> *
>
>
>
> Should the LER which receives the PSC packet, associate the PSC message
> with the MEG/MEP corresponding to the protection LSP - *based on the label
> stack?*
>
>
>
> If the answer is *‘yes’*, then how this association be done in case if
> Penultimate Hop Popping *(PHP) is enabled* where the label in the PSC
> packet will be stripped off when the LER receives the PSC packet.
>
>
>
> *(OR)*
>
>
>
> *      **Associating PSC with protection path based on the MEG/MEP in
> optional TLV :*
>
>
>
> A) Should *‘Remote MEG/MEP’* information of the protection LSP be sent in
> *the ‘Optional TLV’* from the transmitting LER?
>
> If this information is available in the PSC packet, then even if PHP is
> enabled, the LER will be able to associate the PSC packet with MEG/MEP and
> so with a protection path.
>
>
>
> (OR)
>
>
>
> B) *‘Source MEP TLV”* should be sent in *the ‘optional TLV’ in the PSC
> packet ?*
>
>
>
> * 2)       **In case of shared  protection path in 1:n architecture where
> n>1:*
>
> Here the understanding is that one protection path is being shared by ‘n’
> working transport paths.
>
> In this case, *should the PSC message hold any additional information in
> the optional TLVs so as to associate the status conveyed in the PSC message
> against a particular working transport path ?*
>
>
>
> (eg) if  LSP1, LSP2, LSP3 are being protected by the LSP100, then PSC
> messages will be transmitted on LSP100.
>
> In this case, the information such as : PSC request, Fault Path (FPath),
> Data path (Path) exchanged in the PSC message should be for LSP1 (or) LSP2
> (or) LSP3 ?
>
> Should it be discriminated by exchanging relevant information in the
> ‘optional TLV’  ?
>
>
> --
> Best Regards,
> Venkatesan Mahalingam.
>



-- 
Best Regards,
Venkatesan Mahalingam.