Re: [mpls-tp] Problems with SPME as the path segment monitoring tool in MPLS-TP

[David Allan I <[e-mail]>]

HI Maarten:

I think you were missing my point, which is a source of frustration to me as a document editor. There is a set of OAM functions that for MPLS universally exist at each transit node in an MPLS-TP transport path, but there is no one term to describe that set. It is already decomposed into MIPs, half MIPs, source MEP adaptation functions etc. which collectively implement the required functionality at a given sub-layer. That I have to decompose the functions at an intermediate node has been a source of confusion, and has resulted in comments posted against the draft seeking clarification on things that are obvious to you given how you've carved the world up below but not so to others.

I hope that is clearer
Dave

-----Original Message-----
From: Maarten Vissers [mailto:[e-mail]] 
Sent: Monday, July 19, 2010 6:50 AM
To: David Allan I
Cc: [e-mail]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring tool in MPLS-TP

Dave,

>From your words below I get the impression that you do not have a complete understanding of the functionality represented by MEP and MIP and half-MIP functions. Before you continue to make further statements, it is better that you get such understanding. Let me try to educate you in this matter.

We have the following four items:
- OAM messages
- OAM processes generating those messages and processing those messages
- atomic functions containing a specific set of processes
- compound functions containing a specific set of atomic functions

There is a 1:1 mapping of OAM processes into atomic functions.
There is a 1:1 mapping of atomic functions into compound functions.

Note that "POINTS" do not have the capability to generate and insert or extract and process any OAM message or any other element of the frame/packet stream. All processing is performed in processes inside atomic functions.


Termination Source (XXX_TT_So, XXX_FT_So) functions generate a specific subset of OAM messages; i.e. the pro-active OAM messages like CC/CV, LM, DM, RDI.
Termination Sink (XXX_TT_Sk, XXX_FT_Sk) functions terminate and process a specific subset of OAM messages; i.e. the pro-active OAM messages like CC/CV, LM, DM, RDI, LCK, AIS.

Diagnostic Termination Source (XXXDe_TT_So, XXXDi_TT_So, XXXDe_FT_So,
XXXDi_FT_So) functions generate a specific subsets of OAM messages; i.e. the on-demand OAM messages like LBM, LBR, LTM, LTR, LMM, LMR, DMM, DMR, 1DM, TST.
Diagnostic Termination Sink (XXXDe_TT_Sk, XXXDi_TT_Sk, XXXDe_FT_Sk,
XXXDi_FT_S) functions terminate and process a specific subsets of OAM messages; i.e. the on-demand OAM messages like LBM, LBR, LTM, LTR, LMM, LMR, DMM, DMR, 1DM, TST.

Adaptation Source (YYY/XXX_A_So, XXX/ZZZ_A_So) functions generate a specific subset of OAM messages; i.e. the pro-active maintenance signal LCK and the communication channel signals like MCC, SCC, APS, SSM.
Adaptation Sink (YYY/XXX_A_Sk, XXX/ZZZ_A_Sk) functions terminate and process a specific subset of OAM messages and generate a specific subset of OAM messages; i.e. generate the pro-active maintenance signals LCK and AIS and terminate the communication channel signals like MCC, SCC, APS, SSM.

Tandem connection Adaptation Source (XXX/XXX_A_So) functions generate a specific subset of OAM messages; i.e. the pro-active maintenance signal LCK and the communication channel signals like MCC, SCC and APS.
Tandem connection Adaptation Sink (XXX/XXX_A_Sk) functions terminate and process a specific subset of OAM messages and generate a specific subset of OAM messages; i.e. generate the pro-active maintenance signals LCK and AIS and terminate the communication channel signals like MCC, SCC and APS.

A MEP Source function contains the following atomic functions:
XXX/ZZZ_A_So + XXX_(T/F)T_So + XXX/XXX_A_So + XXXDe_(T/F)_A_So A MEP Sink function contains the following atomic functions:
XXX/ZZZ_A_Sk + XXX_(T/F)T_Sk + XXX/XXX_A_Sk + XXXDe_(T/F)_A_Sk

A half-MIP source function contains the following atomic functions:
XXX/XXX_A_So + XXXDi_(T/F)_A_So
A half-MIP sink function contains the following atomic functions:
XXX/XXX_A_Sk + XXXDi_(T/F)_A_Sk

A MIP function contains two back-to-back half-MIP functions. This implies that a MIP function consists of XXXDi_(T/F)_A_Sk + XXX/XXX_A_Sk + XXX/XXX_A_So + XXXDi_(T/F)_A_So in one direction and in the other direction XXXDi_(T/F)_A_So + XXX/XXX_A_So + XXX/XXX_A_Sk + XXXDi_(T/F)_A_Sk

A Server MEP Source function (server layer YYY) contains the following atomic functions:
YYY/XXX_A_So + YYY_(T/F)T_So + YYY/YYY_A_So + YYYDe_(T/F)_A_So A MEP Sink function contains the following atomic functions:
YYY/XXX_A_Sk + YYY_(T/F)T_Sk + YYY/YYY_A_Sk + YYYDe_(T/F)_A_Sk

Please use the terms MIP and MEP in the above context of compound functions representing well defined set of atomic functions and OAM processes.

Regards,
Maarten


-----Original Message-----
From: David Allan I [mailto:[e-mail]]
Sent: vrijdag 16 juli 2010 21:26
To: Maarten Vissers
Cc: [e-mail]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring tool in MPLS-TP

Hi Maarten:

Apologies for the delay in replying. 

>From the below I get the feeling that the term MIP is both hoplessly overloaded and too precisely proscribed. And I am unsure why we are continuing to be pedantic on this issue.

First off, where or how many MIPs reside in a node IMO is orthogonal to the discussion of what it is or does.

If we refer to the generic class of maintenance functions performed by an intermediate node in a path, currently the term MIP does not go far enough as it is contrained to only those that can be interrogated by a source MEP.
IMO origination of AIS, LDI and LKR falls in the class of maintenance functions an intermediate node in a path could and should perform, hence having to have a distinction between MIP functionlaity and those functions at least at a high level does not seem useful. At least not in a network where the correspondence between existence of a MIP and nodes is 1:1. Esp.
when you suggest there is a set of atomic functions that a MIP can be decomposed into not all of which are implemented in all MIPs. E.g. what is a half-MIP, and are there other fractional MIPs we should be considering?

So to restate, I see no reason not to slightly grow the definition of MIP in an IETF context, and eliminate a source of confusion. It is function that both terminates and generates OAM flows at an intemediate node in a path.
For the purposes of equipment recs etc. it can be decomposed further at a later date.

Does that make sense to you?
Best
D

-----Original Message-----
From: Maarten Vissers [mailto:[e-mail]]
Sent: Tuesday, July 13, 2010 5:28 PM
To: David Allan I
Cc: [e-mail]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring tool in MPLS-TP

Dave,

MEP and MIP functions represent two sets of OAM processes. 

Interface ports on MPLS-TP equipment may support MIPs but no MEPs, MEPs but no MIPs, MEPs and MIPs, no MEPs and no MIPs.

Interface ports supporting MEPs may support those only in a "Down"
direction, only in an "Up" direction, or in both "Down" and "Üp" directions.


Interface ports supporting MEPs in the Down direction may support just one, or two or three Down MEPs. Interface ports supporting MEPs in the Up direction may support just one or two Up MEPs.

MEP and MIP funcitons are compound functions and can be decomposed in sets of atomic functions. These atomic functions have Source and Sink parts.
Source atomic functions insert OAM frames, Sink atomic functions extract OAM frames. Adaptation sink functions can also insert AIS and LCK OAM frames.

The Source atomic functions in a MIP insert OAM frames, in response to reception and extraction of OAM frames by a Sink atomic function in that MIP.

The Source atomic functions in a MEP insert OAM frames, in response to reception and extraction of OAM frames by a Sink atomic function in that MEP. The Source atomic functions in a MEP insert OAM frames in response to the reception of a configuration command from management.

MEP and MIP functions describe the OAM functionality supported by an interface port. 

OAM questions that vendors will be asked to answer will include:
- how many transport service down MEP functions are supported per transport service instance on the interface port
- how many transport service up MEP functions are supported per transport service instance on the interface port
- how many transport service instances are supported per interface port
- how many transport service up MEP functions are supported per interface port
- how many transport service down MEP functions are supported per interface port
- is a MIP function supported per transport service instance on the interface port
- is a half-MIP function supportede per transport service instance on the interface port
- how many transport path down MEP functions are supported per transport path instance on the interfae port
- how many trnasport path instances are supported per interface port
- is a MIP function supported per transport path instance on the interface port
- is a half-MIP function supportede per transport path instance on the interface port
- how many section down MEP functions are supported for the section on the interface port
- etc.

Instead of the use of the compound MEP and MIP functions one can use the underlying atomic functions instead to describe the OAM functionality supported by an interface port. The above questions would then be rephrased and include lists of atomic functions.

----

It is very clear from the MIP discussions in the past months, that initial MPLS-TP interface ports may not be able to support MIP functions... Some may support half-MIP funcitons on board, others may not be able to support such functions on board but only emulate such functions in a central controller card in the equipment. Generation of maintenance signal OAM (e.g. AIS) can as such not be allocated to MIP functions. 

Regards,
Maarten