Subject: [mpls-tp] "segment monitoring" reserved label? [was: RE: Is PW a layer of MPLS-TP?]

From: Maarten Vissers <[email-masked]>
Date: Mon, 02 Nov 2009 16:24:23 +0100

In my response to Sasha below I have illustrated possible label stack values
in MPLS-TP when there are two MPLS-TP layers (VC, VP), each having some
segment monitoring active. 
 
With todays specification it will be impossible to infer from the label
values which labels belong to the service instance (VC), which to the tunnel
instance (VP) and which to a segment of the service instance, or a segment
of the tunnel instance.
 
As a service instance (VC) segment and a tunnel instance (VP) segment have a
1-to-1 relation with the service instance resp. tunnel instance, it would be
possible to use a reserved label to identify the label stack entry header as
a "segment monitoring" label. In the example below I used Label value 12 as
illustration.
 
 Current label stack values example:
==========================
- 217 - 65 - 458- 6534 - 9123 - 100567 - 873 - nibble=0000
which is accompanied by label stacks with values 
- 13 (virtual section OAM)
- 217 - 13 (virtual path, segment 1 OAM)
- 217 - 65 - 13 (virtual path, segment 2 OAM)
- 217 - 65 - 458 -13 (virtual path network connection OAM)
- 217 - 65 - 458 - 6534 - 13 (virtual channel, segment 1 OAM)
- 217 - 65 - 458 - 6534 - 9123 - 13 (virtual channel, segment 2 OAM)
- 217 - 65 - 458 - 6534 - 9123 - 100567 - 13 (virtual channel, segment 3
OAM) 
- 217 - 65 - 458 - 6534 - 9123 - 100567 - 873 - nibble=0001 (virtual
channel, network connection OAM).
 
Label stack values example with "segment monitoring" label:
============================================
- 217 - 12 - 12 - 6534 - 12 - 12 - 12 - nibble=0000
which is accompanied by label stacks with values 
- 13 (virtual section OAM)
- 217 - 13 (virtual path, segment 1 OAM)
- 217 - 12 - 13 (virtual path, segment 2 OAM)
- 217 - 12 - 12 -13 (virtual path network connection OAM)
- 217 - 12 - 12 - 6534 - 13 (virtual channel, segment 1 OAM)
- 217 - 12 - 12 - 6534 - 12 - 13 (virtual channel, segment 2 OAM)
- 217 - 12 - 12 - 6534 - 12 - 12 - 13 (virtual channel, segment 3 OAM) 
- 217 - 12 - 12 - 6534 - 12 - 12 - 12 - nibble=0001 (virtual channel,
network connection OAM).
 
Use of a "segment monitoring" label helps to understand the signal structure
and its components as it separates the service and tunnel instance (VC/VP)
labels from their segment monitoring labels.
 
Would the introduction of such "segment monitoring" label with a reserved
label value be helpful in the operation of MPLS-TP?
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Vissers
Sent: donderdag 29 oktober 2009 13:19
To: 'Alexander Vainshtein'
Cc: [email-masked]
Subject: Re: [mpls-tp] Is PW a layer of MPLS-TP?

Sasha,
 
I noted a small mistake in the second and third label stacks (due to
copy/paste of previous lines). Virtual channel, network connection OAM is
implemented by PW OAM and as such does not have the GAL (label_13); instead
the 4-bit nibble distinguishes between client data and OAM.
 
The following corrections have to be applied:
 
replace: 
- 217 - 65 - 458- 6534 - 9123 - 100567 - 873 
by: 
- 217 - 65 - 458- 6534 - 9123 - 100567 - 873 - nibble=0000
 
replace:
- 217 - 65 - 458 - 6534 - 9123 - 100567 - 873 -13 (virtual channel, network
connection OAM).
by:
- 217 - 65 - 458 - 6534 - 9123 - 100567 - 873 - nibble=0001 (virtual
channel, network connection OAM).
 
replace:
- 217 - 12 - 12 - 6534 - 12 - 12 - 12 
by:
- 217 - 12 - 12 - 6534 - 12 - 12 - 12 - nibble=0000
 
replace:
- 217 - 12 - 12 - 6534 - 12 - 12 - 12 -13 (virtual channel, network
connection OAM).
by:
- 217 - 12 - 12 - 6534 - 12 - 12 - 12 - nibble=0001 (virtual channel,
network connection OAM).
 
Regards,
Maarrten
 
  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Vissers
Sent: donderdag 29 oktober 2009 12:52
To: 'Alexander Vainshtein'
Cc: [email-masked]
Subject: Re: [mpls-tp] Is PW a layer of MPLS-TP?

Sasha,
 
> Layering of MPLS-TP networks is not in any way reflected in the MPLS-TP
data plane.
> (This is based on the fact that your description of what constitutes a
layer do not refer to
> any data plane aspects of MPLS-TP.)
 
The data plane formats in MPLS-TP are the result of an evolution of existing
header/frame formats and capabilities in existing router implementations
(LSE header stacking). T-MPLS frame formats were an evolution of other
existing header/frame formats and capabilities present in transport
equipment.
 
T-MPLS frame formats and T-MPLS VC/VP layers had a strong coupling; i.e. a
non-reserved label stack entry header corresponded with either a VC or VP.
Segment monitoirng maintenance entity levels were encoded using a MEG Level
field, separating the fields to identify (1) a client signal in an aggregate
stream and (2) a segment maintenance entity level. This would have resulted
in a following label stack when a VP with 2 segment monitoring levels
carrying a VC with 3 segment monitoring levels would be present on an
interface:
- 217 - 6534 
which is accompanied by label stacks with values 
- 14 - MEL=0 (virtual section OAM)
- 217 - 14 - MEL=0 (virtual path, segment 1 OAM)
- 217 - 14 - MEL=1  (virtual path, segment 2 OAM)
- 217 - 14 - MEL=2 (virtual path network connection OAM)
- 217 - 6534 - 14 - MEL=0  (virtual channel, segment 1 OAM)
- 217 - 6534 - 14 - MEL=1 (virtual channel, segment 2 OAM)
- 217 - 6534 - 14 - MEL=2 (virtual channel, segment 3 OAM) 
- 217 - 6534 - 14 - MEL=3 (virtual channel, network connection OAM).
 
217 identifies the VP and 6534 identifies a VC within the VP. 14 identifies
that the payload carries OAM and the MEL identifies the different segment
and network connection OAM entities. Very simple as such, and a strong
reflection of layering in the data plane frame format encoding.
 
The choice in MPLS-TP to deploy label stack entry headers to identify
segment monitoring maintenance entity levels removed the coupling between a
label stack entry header and a layer network signal instance. That decision
**impacted the encoding of specific elements of information**, it did **not
impact the functional model of the layer network**. The above label stack
example has as such been replaced by the following:
 - 217 - 65 - 458- 6534 - 9123 - 100567 - 873 
which is accompanied by label stacks with values 
- 13 (virtual section OAM)
- 217 - 13 (virtual path, segment 1 OAM)
- 217 - 65 - 13 (virtual path, segment 2 OAM)
- 217 - 65 - 458 -13 (virtual path network connection OAM)
- 217 - 65 - 458 - 6534 - 13 (virtual channel, segment 1 OAM)
- 217 - 65 - 458 - 6534 - 9123 - 13 (virtual channel, segment 2 OAM)
- 217 - 65 - 458 - 6534 - 9123 - 100567 - 13 (virtual channel, segment 3
OAM) 
- 217 - 65 - 458 - 6534 - 9123 - 100567 - 873 -13 (virtual channel, network
connection OAM).
 
>From this label stack it is totally unclear if there is 
- a VC carried over a section layer with 6 segment monitoring levels, or
- a VP carried over a section layer with
  # 5 VP segment monitoring levels and a VC without segment monitoring, or
  # 4 VP segment monitoring levels and a VC with 1 segment monitoring level,
or
  # 3 VP segment monitoring levels and a VC with 2 segment monitoring
levels, or 
  # 2 VP segment monitoring levels and a VC with 3 segment monitoring
levels, or 
  # 1 VP segment monitoring levels and a VC with 4 segment monitoring
levels, or
  # no VP segment monitoring levels and a VC with 5segment monitoring
levels.
 
It is clear that there is no reflection of the layering in the data plane
frame format encoding... but this has been a choice of the group.
 
If it would be important to reflec the layering in the data plane frame
formats, then it is possible to do so in a simple means. I.e. when a label
stack entry header is added at the input of a segment MEP it is possible to
insert a reserved label value (e.g. 12) into the label field. If you do this
you restore the coupling between layering and data plane frame formats. If
you now look into the label stack, you will find label stack entry headers
with a normal label value (>=16), label stack entry headers with label value
12 and label stack entry headers with label value 13. Taking the same
example as above, you would get:
- 217 - 12 - 12 - 6534 - 12 - 12 - 12 
which is accompanied by label stacks with values 
- 13 (virtual section OAM)
- 217 - 13 (virtual path, segment 1 OAM)
- 217 - 12 - 13 (virtual path, segment 2 OAM)
- 217 - 12 - 12 -13 (virtual path network connection OAM)
- 217 - 12 - 12 - 6534 - 13 (virtual channel, segment 1 OAM)
- 217 - 12 - 12 - 6534 - 12 - 13 (virtual channel, segment 2 OAM)
- 217 - 12 - 12 - 6534 - 12 - 12 - 13 (virtual channel, segment 3 OAM) 
- 217 - 12 - 12 - 6534 - 12 - 12 - 12 -13 (virtual channel, network
connection OAM).
 
217 identifies the VP, 6534 identifies one of the VCs within the VP. This is
immediately visible from this enhanced encoding of segment monitoring label
fields in label stack entry headers. And by counting the number of label
stack entry headers with label value 12 it is possible to identify the
different OAM frames.
 
I hope it is clear to you now that the three encodings presented above can
be used with the same VC, VP and VS layering. The layering is as such
independent of the choosen encoding. Each encoding has its pro's and con's.
The existing, middle encoding is however not friendly for us people, as it
does not give us any idea of the signal structure. In that sense it is the
worst possible encoding format.
 
Regards,
Maarten
 
  _____  

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: woensdag 28 oktober 2009 20:56
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] Is PW a layer of MPLS-TP?

Maarten,
Lots of thanks for a prompt response.

I must admit that I read your answer to my question #1 as following:

Layering of MPLS-TP networks is not in any way reflected in the MPLS-TP data
plane. 

(This is based on the fact that your description of what constitutes a layer
do not refer to any data plane aspects of MPLS-TP.)

Of course, the situation is quite different with both SONET/SDH transport
and ATM. 

You effectively claim that transport networks must follow certain
architectural rules regardless of how they actually work. Personally I find
this claim highly questionable.

As for my question #2, I must admit that I find the analogy between ATM and
MPLS (or MPLS-TP) inappropriate. Hence I fail to interpret your
explanations.

Regards,

     Sasha

________________________________________
From: Maarten Vissers [[email-masked]]
Sent: Wednesday, October 28, 2009 9:00 PM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: RE: [mpls-tp] Is PW a layer of MPLS-TP?

Sasha,

See inline..

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: woensdag 28 oktober 2009 16:19
To: Maarten Vissers
Cc: 'Adrian Farrel'; [email-masked]
Subject: RE: [mpls-tp] Is PW a layer of MPLS-TP?

Maarten,
Two naive questions if you do not mind:

1. Do I read you correctly that, in MPLS-TP, layering is imposed on the
network in order to structure some
   OAM entities?  Per se (in the data plane) layering  simply does not
exist, and hence the way in which it
   is imposed is actually arbitrary?

[mv] No. Layering is imposed on a transport network in order to scale the
transport network.

[mv] A layer contains a set of transport entities that have the same
purpose; e.g.
- customer service carrying transport entities (service/channel layer)
connecting two (or more) UNI-N ports,
- service/channel layer carrying transport entities (tunnel/path layer)
connecting two PEs.

[mv] Transport entities may be owned by multiple operators/service
providers, or may be protected. In this case the transport entity will
contain multiple maintenance entity groups.

[mv] Each maintenance entity group operates an instance of pro-active and
on-demand OAM.

[mv] There are multiple methods to identify OAM of a specific maintenance
entity group. E.g. time based (SDH, OTN), MEG level identifier based
(Ethernet), reserved label based (ATM), label stack based (MPLS-TP).

[mv] Connection management (NMS, GMPLS) controls the set up of transport
entities within a layer network. In addition, connection management controls
the activation and configuration of MEP functions within a transport entity
and the activation and configuration of protection switching within a
transport entity.

[mv] Example: to set up a 1:1 protected service/channel layer transport
entity (protected MPLS-TP VC), connection management will
- compute the path through the network from UNI-N to UNI-N, including the
Working segment and Protection segment
- reserve bandwidth on each link traversed by the protected MPLS-TP VC
- configure the link connections in the links (supported by tunnel/path
layer transport entities), including the assignment of label values; i.e. PW
label values outside the Working/Protection segments and LSP label values
inside the Working/Protection segments
- configure the matrix connections in the PE nodes to interconnect two or
three NNI ports
- activate the SNC/S protection switching bridge and selector functions in
PE nodes
- configure the NCM MEP functions at the UNI-N ports in T-PE nodes
- activate and configure the TCM MEP functions at the NNI ports in PE nodes
at the end of the Working segment and Protection segment, including
assignment of a label value; i.e a PW label value in this case
- activate and configure the MIP functions at the NNI ports in PE nodes;
MIPs within the MPLS-TP VC outside the Working/Protection segments are
configured to react to PW OAM messages, MIPs inside the Working/Protection
segments are configured to react to LSP OAM messages.

[mv] It is unfortunate that PW OAM and LSP OAM have different frame
formats... as a consequence the MPLS-TP VC MIP functions need to be
configured to react to either PW OAM, or LSP OAM.

2. What is the difference between the MS-PW MEG and an LSP MEG? Especially
in the MPLS-TP
    landscape which presumably requires bi-directional LSPs?

[mv] In the MPLS-TP service/channel layer transport entities (the MPLS-TP
Virtual Channels) there will always be one network connection monitoring
maintenance entity group. This MEG will be using MPLS-TP PW OAM ("PW MEG").
There may be one or more tandem connection monitoring maintenance entity
groups, which monitor a segment of the MPLS-TP VC. These MEGs will be using
MPLS-TP LSP OAM ("LSP MEG").

[mv] In the MPLS-TP tunnel/path layer transport entities (the MPLS-TP
Virtual Paths) there will always be one network connection monitoring
maintenance entity group. This MEG will be using MPLS-TP LSP OAM ("LSP
MEG"). There may be one or more tandem connection monitoring maintenance
entity groups, which monitor a segment of the MPLS-TP VP. These MEGs will be
using MPLS-TP LSP OAM ("LSP MEG").

Regards,
Maarten

My 2c,
     Sasha

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> Sent: Wednesday, October 28, 2009 5:01 PM
> To: 'Adrian Farrel'; [email-masked]
> Subject: Re: [mpls-tp] Is PW a layer of MPLS-TP?
>
> Adrian,
>
> When I look at the MPLS-TP landscape then I see two different types of
> layer
> networks:
> 1) layer network A which contains a MS-PW MEG level and zero or more
> LSP MEG levels
> 2) layer network B which contains one or more LSP MEG levels.
>
> With these two layer networks it is possible to construct a MPLS-TP
> Virtual Channel layer network using layer network A, and to construct
> a MPLS-TP Virtual Path layer network using layer netowrk B. It is also
> possible to construct a MPLS-TP Virtual Section layer network using
> layer network B, which would be necessary when the (non-MPLS)
> transmission media layer does not support a section layer.
>
> A MPLS-TP VP signal carries n (n>=1) MPLS-TP VC signals.
>
> A MPLS-TP VS signal carries either n (n>=1) MPLS-TP VP signals (VP
> over VS), or n (n>=1) MPLS-TP VC signals (VC over VS).
>
> The MPLS-TP VC layer deploys MPLS-TP PW OAM within the MS-PW MEG level
> and LSP OAM within the LSP MEG levels (for each MPLS-TP VC segment).
> As a consequence, a MPLS-TP VC MIP function must support both PW OAM
> and LSP OAM; which of these two OAM types is supported by a specific
> MPLS-TP VC MIP function on an NNI port depends on the lowest MPLS-TP
> MEG level. MPLS_TP VC MIP function on an NNI on a PE node must thus be
> configurable for PW OAM or LSP OAM. When the MPLS-TP VC has only a
> MS-PW MEG level acitve, the MPLS-TP VC MIP functions must be
> responsive to MPLS-TP PW OAM. When the MPLS-TP VC has both the MS-PW
> MEG level and one or more LSP MEG levels active (i.e.
> segment monitoring), then the MPLS-TP VC MIP function within the
> segment must be responsive to LSP OAM.
>
> The PW is as such an integral part of MPLS-TP technology and layer
> networks.
> It represents one MEG level (the Network Connection Monitoring (NCM)
> MEG
> level) within the MPLS-TP VC layer.
>
> -------------------
>
> There is an alternative view possible when MPLS-TP only provides a
> Virtual Path layer network, and this MPLS-TP VP layer netowrk is
> combined with an Ethernet Virtual Channel layer network. In this
> combination there is no MPLS-TP Virtual Channel layer network and
> there is no need for any MPLS-TP PW OAM (refer to C745, SG15 Sep/Oct
> 2009). The OAM used in the Virtual Channel layer is the ETH OAM
> specified in Y.1731/G.8021. The "PW Label Stack Entry" header carries
> the vlan_identifier information in its 20-bit PW Label field, and the
> priority and drop_eligible information in its 3-bit TC field.
>
> In this case the "PW" represents a label header and there is no PW
> layer (or more precise no "layer network A" as described above and
> thus no "PW MEG level"). MPLS-TP would then only contain LSPs (i.e.
> only a "layer network B"
> as described above).
>
> ---------------------
>
>
> My understanding is that both alternatives will be present in the
> packet transport network; some operators have build or are building
> their PTN with MPLS-TP VC included, others have build or are building
> their PTN without MPLS-TP VC layer.
>
> Regards,
> Maarten
>
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: woensdag 28 oktober 2009 14:41
> To: [email-masked]
> Subject: [mpls-tp] Is PW a layer of MPLS-TP?
>
> Hi,
>
> I am trying this question again with a different subject line.
>
> It would be helpful to have more answers than just Neil's (not that I
> don't value his view, but one person doesn't make consensus!)
>
> My question:
> Hasn't the work on the MPLS-TP Framework draft judged PW to be a
> client of MPLS-TP?
> That is, PW is not a layer of MPLS-TP, but the client.
> Doesn't that mean that PW survivability is out of scope for the
> MPLS-TP Survivability I-D?
>
> Thanks,
> Adrian
> ----- Original Message -----
> From: "Adrian Farrel" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, October 27, 2009 9:49 PM
> Subject: [mpls-tp] Resurfacing of the same old question :-(
>
>
> > Hi,
> >
> > In today's review of the MPLS-TP Survivability Framework I
> was asked to
> > add a short section explaining what levels of protection
> (link, segment,
> > concatenated segment, e2e, service) were applicable in each
> of the MPLS
> > LSP layer and the PW layer of the MPLS-TP network.
> >
> > I have drafted this text, which is simple enough, and Nurit
> is reviewing
> > it before I circulate it more widely.
> >
> > But, now I have written it I am worried!
> >
> > Didn't we decide in the MPLS-TP Framework that PW is a
> client of MPLS-TP?
> > Doesn't that actually mean that PW survivability is
> *entirely* out of
> > scope for this document?
> > Client layer survivability is an interesting topic, and
> each MPLS-TP
> > client layer should document its own survivability in its
> own document.
> > For example, it looks like we are observing (separate
> thread) that IP is
> > an acceptable client of MPLS-TP. I am sure that we do not
> propose to
> > document IP survivability techniques in this document.
> >
> > So, how should the Survivability Framework be positioning PW
> > survivability?
> >
> > Thanks for any advice,
> > Adrian
> > _______________________________________________
> > mpls-tp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> >
>
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
> =