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

["Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[e-mail]>]

Venkat, hi

 

Thank you for your question - sorry for the slight delay in responding,
however, I was on vacation last week.

 

Regarding your question - Yes the association of the PSC message to the
protection path is via the LSP Label.

In answer to your more specific questions:

1. As stated in draft-ietf-mpls-tp-data-plane (section 3.1.1) PHP MUST
be disabled on MPLS-TP LSP's, therefore the situation that you describe
is not relevant to MPLS-TP.  As to applicability to other MPLS networks,
it would need to be addressed separately.  (Although I would assume that
use of the control-plane protection would be more applicable.)

 

2. As stated in the draft the applicability to 1:n protection is
out-of-scope for this document and should be addressed in a future
document.

 

Hope this helps,

yaacov

 

________________________________

From: ext venkatesan mahalingam [mailto:[e-mail]] 
Sent: Friday, August 06, 2010 12:00
To: [e-mail]; mpls; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: Association of PSC messages to a protection path

 

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.