Subject: Re: [mpls-tp] about open discussion about MIPMEP in MPLS-TP networks

From: venkatesan mahalingam <[email-masked]>
Date: Thu, 25 Nov 2010 01:28:14 +0530

Dear Maarten,

If you can explain your point " To realize this required behaviour, it is
necessary that the sub-path MEP functions on MPLS-TP NNI ports can read some
of the bits below the top label, and when there is a match with an expected
value can extract the packet for further OAM processing" with an example
diagram, it might ease the debate and to take a conclusion.

Do you have any such scenario captured anywhere in IETF mailing-list or is
it possible to share any diagram?
Thanks & Regards,
Venkat.
-----Original Message-----

From: [email-masked]
[*mailto:[email-masked]*<[email-masked]>]
On Behalf Of Maarten Vissers

Sent: Wednesday, November 24, 2010 6:24 PM

To: 'Eric Osborne (eosborne)'; 'Alexander Vainshtein'

Cc: MPLS TP

Subject: Re: [mpls-tp] about open discussion about MIPMEP in MPLS-TP
networks

Eric,

There are a couple of architectural different entities supported by means of
stacking labels:

1) connection hierarchy: multiple client LSP/PW/VPLS signals are transported
over a server LSP connection, which latter was set up under control of
network planning to provide for a virtual link between PE nodes

2) OAM maintenance entity hierarchy: multiple OAM maintenance entity levels
may exist within a LSP or PW connection. One end-to-end LSP or PW
maintenance entity level will exist by default when the LSP or PW connection
is created, other sub-path maintenance entity levels between arbitrary
points along the connection may be created during LSP or PW connection set
up, or after set up. In all cases the creation of such sub-path maintenance
entities should not change the LSP or PW connection configuration.

3) when a group of LSP or PW signals is to be protected in the network, it
is an option to protect each LSP or PW signal independently, or to protect
the group of LSP or PW signals by means of multiplexing those signals into a
group protection dedicated server LSP signal. The latter approach has
scalability advantages.

All three entities are today supported by label stacking. Label stacking is
the correct method for items 1 and 3.

For item 2 label stacking is not the right method, at least with the current
specification in which a new label is added at the top of the stack. This
approach changes the PW/LSP connection configuration in the network, which
is not allowed.

What is required is the behaviour present in e.g. OTN ODU connections and
Ethernet VLAN connections. In those two cases, it is possible to activate
additional OAM insertion/extraction at points along the connection without
touching the configuration of the connection in the matrices passed by the
connection.

For MPLS-TP this would imply that it should be possible to set up a PW or
LSP connection with OAM insertion/extraction at the endpoints only, and then
be able to just activate additional OAM insertion/extraction functions

(MEPs) at arbitrary points along the connection. The value of labels in the
label stack should not be changed.

To realize this required behaviour, it is necessary that the sub-path MEP
functions on MPLS-TP NNI ports can read some of the bits below the top
label, and when there is a match with an expected value can extract the
packet for further OAM processing.

Regards,

Maarten

> -----Original Message-----

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 25 Nov 2010 09:13:25 +0100

Dear Venkat,

Figures 1 and 2 below illustrate an LSP OAM packet and a PW OAM packet with
a MEG Level (MEL) field located in three Reserved bits of the ACH; i.e. in
bits 8, 9 and 10 of the ACH.

A sub-Path LSP MEP Source function would insert the LSP OAM packets of
Figure 1 and a sub-Path PW MEP Source function would insert the PW OAM
packets of Figure 2. Sub-Path MEP Source functions do not need to insert an
additional label stack entry header (as is required today).

A sub-Path LSP MEP Sink function reads bits 32-51, 55 and 72-74 of a
labelled LSP packet and compares the value of those bits with the pattern 
0000 0000 0000 0000 1101 1 xxx, in which the 'xxx' contains the value of the
MEP's MEG Level. If there is a match, the sub-Path LSP MEP Sink function
will have identified the LSP packet as an LSP OAM packet for this sub-Path
MEP Sink function and extract the packet for further processing.

A sub-Path PW MEP Sink function reads bits 32-35 and 40-42 of a labelled PW
packet and compares the value of those bits with the pattern 
0001 xxx, in which the 'xxx' contains the value of the MEP's MEG Level. If
there is a match, the sub-Path PW MEP Sink function will have identified the
PW packet as an PW OAM packet for this sub-Path MEP Sink function and
extract the packet for further processing.

Sub-Path MEP sink functions do not have to extract a label stack entry
header (as is required today).

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               LSP Label               |  TC |0|       TTL     |  0..31
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  GAL                  |  TC |1|       TTL     | 32..63
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1|Version| MEL |Reserved |         Channel Type          | 64..95
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  ACH TLV Header (if present)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               ~
   ~                     Zero or more ACH TLVs                     ~
   ~                           (if present)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               ~
   ~                         G-ACh Message                         ~
   ~                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     			Figure 1 - LSP OAM packet

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               PW Label                |  TC |1|       TTL     |  0..31
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1|Version| MEL |Reserved |         Channel Type          | 32..63
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  ACH TLV Header (if present)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               ~
   ~                     Zero or more ACH TLVs                     ~
   ~                           (if present)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               ~
   ~                         G-ACh Message                         ~
   ~                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 	Figure 2 - PW OAM packet

Regards,
Maarten

From: venkatesan mahalingam [mailto:[email-masked]] 
Sent: 24 November 2010 20:58
To: Maarten Vissers; [email-masked]
Subject: Re: [mpls-tp] about open discussion about MIPMEP in MPLS-TP
networks

Dear Maarten,

Thanks & Regards,
Venkat.

-----Original Message-----
From: [email-masked] [
mailto:[email-masked]] On Behalf Of Maarten Vissers 
Sent: Wednesday, November 24, 2010 6:24 PM
To: 'Eric Osborne (eosborne)'; 'Alexander Vainshtein'
Cc: MPLS TP
Subject: Re: [mpls-tp] about open discussion about MIPMEP in MPLS-TP
networks

Eric,

Regards,
Maarten