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

From: Sonny Thorelli <[email-masked]>
Date: Mon, 26 Jul 2010 16:09:53 +0200

Press rwr
----- Ursprungligt meddelande -----
Från:"Maarten Vissers" <[email-masked]>
Till:"David Allan I" <[email-masked]>
Kopia:"[email-masked]" <[email-masked]>
Skickat:26-07-2010 11:02 fm
Ämne:Re: [mpls-tp] Problems with SPME as the path segment monitoring tool in MPLS-TP

Retry... Original email 43k...
________________________________

From: Maarten Vissers [mailto:[email-masked]]
Sent: maandag 26 juli 2010 10:40
To: 'David Allan I'
Cc: [email-masked]'
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Hi Dave,

I completely agree with you in the sense that there will be MPLS-TP
equipment that will have all functions supported. I am also very much aware
that we will have small Network Termination equipment that will only have a
subset of functions. Then I expect that there will be MPLS-TP equipment that
has installed a subset of line and trib card types, and consequentially also
has only another subset of functions.

But if we would describe the maximum functionality that may be required on
trib and line cards (ignoring FRR at the moment), then we can do so. In my
opinion the following would be part of such maximum functionality (but not
the maximum functionality as more multiplexing may have to be supported):

Line Cards, Ingress port
=================
1) PHY Termination Sink
2) PHY to MPLS-TP Section Adaptation Sink
3) MPLS-TP Section TCM MEP Sink (Section SPME MEP Sink)
4) MPLS-TP Section NCM MEP Sink (Section MEP Sink)
5) MPLS-TP Section to Transport Path Adaptation Sink (demuxing)
6) MPLS-TP Transport Path TCM MEP Sink (TP SPME MEP Sink)
7) MPLS-TP Transport Path NCM MEP Sink (TP MEP Sink)
8) MPLS-TP Transport Path to Transport Section Adaptation Sink (demuxing)
9) MPLS-TP Transport Service TCM MEP Sink (SPME MEP Sink) and Ethernet TCM
MEP Sink (SPME MEP Sink)
10) MPLS-TP Transport Service TCM MEP Sink (SPME MEP Sink) and Ethernet TCM
MEP Sink (SPME MEP Sink)
11) MPLS-TP Transport Service TCM MEP Sink (SPME MEP Sink) and Ethernet TCM
MEP Sink (SPME MEP Sink)
12) -
13) MPLS-TP Transport Service MIP (PW, service-LSP MIPs) and Ethernet MIP
14) MPLS-TP Transport Service TCM MEP Source (SPME MEP Source) and Ethernet
TCM MEP Source (SPME MEP Source)
15) MPLS-TP Transport Path or Service TCM MEP Source (SPME MEP Source) and
Ethernet TCM MEP Source (SPME MEP Source)

Line Cards, Egress port
=================
1) PHY Termination Source
2) PHY to MPLS-TP Section Adaptation Source
3) MPLS-TP Section TCM MEP Source (Section SPME MEP Source)
4) MPLS-TP Section NCM MEP Source (Section MEP Source)
5) MPLS-TP Section to Transport Path Adaptation Source (muxing)
6) MPLS-TP Transport Path TCM MEP Source (TP SPME MEP Source)
7) MPLS-TP Transport Path NCM MEP Source (TP MEP Source)
8) MPLS-TP Transport Path to Transport Section Adaptation Source (muxing)
9) MPLS-TP Transport Service TCM MEP Source (SPME MEP Source) and Ethernet
TCM MEP Sink (SPME MEP Source)
10) MPLS-TP Transport Service TCM MEP Source (SPME MEP Source) and Ethernet
TCM MEP Sink (SPME MEP Source)
11) MPLS-TP Transport Service TCM MEP Source (SPME MEP Source) and Ethernet
TCM MEP Sink (SPME MEP Source)
12) Ethernet Traffic Conditioning function
13) MPLS-TP Transport Path or Transport Service MIP (PW, service-LSP,
transport-LSP, PSME-LSP MIPs) and Ethernet MIP
14) MPLS-TP Transport Service TCM MEP Sink (SPME MEP Sink) and Ethernet TCM
MEP Sink (SPME MEP Sink)
15) MPLS-TP Transport Path or Service TCM MEP Sink (SPME MEP Sink) and
Ethernet TCM MEP Sink (SPME MEP Sink)

Trib Cards, Ingress port
=================
0) client native ingress processing
1) MPLS-TP Transport Service to client Adaptation Source (mapping) and
Ethernet to Ethernet client Adaptation Souce (mapping)
2) MPLS-TP Transport Service NCM MEP Source (PW, service-LSP MEP Source) and
Ethernet NCM or TCM MEP Source
3) MPLS-TP Transport Service TCM MEP Source (SPME MEP Source) and Ethernet
TCM MEP Source
4) MPLS-TP Transport Service TCM MEP Source (SPME MEP Source) and Ethernet
TCM MEP Source

Trib Cards, Egress port
=================
0) client native egress processing
1) MPLS-TP Transport Service to client Adaptation Sink (demapping) and
Ethernet to Ethernet client Adaptation Sink (demapping)
2) MPLS-TP Transport Service NCM MEP Sink (PW, service-LSP MEP Sink ) and
Ethernet NCM or TCM MEP Sink
3) MPLS-TP Transport Service TCM MEP Sink (SPME MEP Sink ) and Ethernet TCM
MEP Sink
4) MPLS-TP Transport Service TCM MEP Sink (SPME MEP Sink ) and Ethernet TCM
MEP Sink

If you look athe the required label processing required in those cards, then
this can be summarized as follows (if I am not miscounting):
- Line Cards, Ingress port: pop up to 7 labels, swap 1 label, push up to 2
labels
- Line Cards, Egress port: push up to 7 labels, swap 1 label, pop up to 2
labels
- Trib Cards, Ingress port: push up to 3 labels
- Trib Cards, Egress port: pop up to 3 labels.

If you look athe the required OAM processing required in those cards, then
this can be summarized as follows (if I am not miscounting):
- Line Cards, Ingress port: terminate up to 7 MPLS-TP OAM MEP sets and 3 Eth
OAM MEP sets, reply to 1 MPLS-TP and Ethernet OAM MIP set, insert up to 2
MPLS-TP and Eth OAM MEP sets
- Line Cards, Egress port: insert up to 7 MPLS-TP OAM MEP sets and 3 Eth OAM
MEP sets, reply to 1 MPLS-TP and Ethernet OAM MIP set, terminate up to 2
MPLS-TP and Eth OAM MEP sets
- Trib Cards, Ingress port: insert up to 3 MPLS-TP and Eth OAM MEP sets
- Trib Cards, Egress port: terminate up to 3 MPLS-TP and Eth OAM MEP sets.

I seriously doubt if initial MPLS-TP line and trib cards will be able to
support the above label stacking and OAM numbers. In many cases those
numbers do not have to be supported. E.g. a line card on a node used to
interconnect Transport Path layer transport paths could already perform its
basic function when supporting only a subset of the listed functions.

Note that the described line cards support two-stage
multiplexing/demultiplexing. With FRR three-stage multiplexing may be
required and large networks may deploy additional muxing stages to reduce
number of LSPs in core domains further.

Regards,
Maarten
PS. Note that OTN is having a flexible ODU hierarchy as well today. Many OTN
networks will just need two ODU layers, large OTN networks may use more. For
1st (2.5G timeslots) to 2nd (1.25G timeslots) Generation OTN interworking an
additional, intermediate ODU level will be used as well. Discussions in
CCAMP this week will be addressing the control of this flexible ODU
hierarchy.

________________________________

From: David Allan I [mailto:[email-masked]]
Sent: woensdag 21 juli 2010 23:44
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Hi Maarten:

There are several things that nag me in this answer, bear with me here...

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Wednesday, July 21, 2010 2:28 AM
To: David Allan I
Cc: [email-masked]
Subject: RE: [mpls-tp] Problems with SPME as the path segment monitoring
tool in MPLS-TP

Hi Dave,

The rationale for the allocation of OAM functions to atomic functions and
atomic functions is to describe the OAM functions that come always together
and those that may be together or may be separate.

Operators can express the required OAM functions in their nodes by means of
expression the required set of atomic functions in a node. And vendors can
express the provided set of OAM functions in a node by presenting the
functional model of their nodes in terms of atomic functions supported.

A Transport Service Switching node has different sets of atomic functions
(and thus OAM) then a Transport Path Switching node, and both nodes have
again a different set of atomic functions (and thus OAM) then a Network
Termination node.

Actually I'd challenge that. What we have in MPLS-TP is literal recursion of
sub-layers, or label levels, or whatever (choose your term), with the
requisite functionality for a given relative point in a given LSP path being
common and independent of the specific sub-layer the LSP is associated with.
Further the LSP hierarchy will be arbitrary from LSP to LSP, some may have
SPMEs, some may not all switched from a common LFIB, the LFIB being
independent of the sub-layering.(unlike for example ethernet which required
the concept of MEL, or OTN which has a switching hierarchy of it's own).

For legacy reasons we have multiple OAM encapsulations, and we have perhaps
additional functionalities (e.g. CFI) that are unique to specific sub-layers
typically the layering bookends of service layer and section. IMO those are
outliers of the common OAM set.

otherwise the only potential distinction is "is this an internal interface
or a business interface?"

>From the POV of modelling the instrumentation of an individual LSP, the
placement of certain functions likely matters IMO with the ideal being that
all intermediate functions are effectively a singluarity such that there is
no aspect "uncovered"or uninstrumented. But that is modelling, not
implementation and only examining a fraction of the overall requirements of
an MPLS node in isolation.

But from my point of view every MPLS node (in an object oriented sense)
implements the full set of ALL atomic functions that can be associated with
the maintenance of an LSP, as the node may assume any role (termination,
transit etc, for any of the sub-layers associated the MPLS-TP architecture.

My reason for saying that is that my experience is that the degree of nodal
specialization you are discussing below does not actually exist. The
majority of nodes in a network will host a UNI and all will be required to
have that capability, to avoid the need to deploy a second box to meet a
customer request.  Ergo, it will be expected to do everything. At least that
is how the RFPs will read.

So to summarize,

1) OAM functionality will largely be common/identical across the set of
MPLS-TP sub-layers as we are discussing simple and arbitrary recursion in
the label stack.
2) The set of functions required for a given LSP at an intermediate node
will typically be the complete set of functions required at an intermediate
node.
3) The existence of SPMEs (the TP version of carrier supporting carrier)
simply means that a business interface is one where only specific sub-layers
are exposed, with little ramification on the implementation of
instrumentation of the sub-layers in general.
4) All nodes will implement the complete set of OAM functionality as all
nodes can assume any role in any sub-layer.

I appreciate that the modelling background of what you present is
path/fixed-hierarchy based, it is one of several views required and
necessary to both conceptualize and eventually manage this stuff. I'd assert
it is not the only view and perhaps is limited by the fixed and structured
hierarchical nature of TDM/SDH/OTN networks that does not exist in the
packet world.

my 2 cents

cheers
D

_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp