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

[Maarten Vissers <[e-mail]>]

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