Re: [mpls-tp] MPLS-TP protocol/payload type usage in OAMExtractionProcess

[Maarten Vissers <[e-mail]>]

Shahram,
 
Both methods
1) choose the Ethernet layer as unifying layer, which is essentially what
MEF advocates with their EVC layer
2) introduce a MPLS VC (true co-ps MPLS-TP MS-PW) layer for p2p and p2mp
services 
will work if we reuse the PWE3 encapsulations to map the p2p and p2mp PWE3
clients into the EVCs.
 
What we need to do for this latter item is to request Ethertype values for
each of the PWE3 clients. 
Below is a list of such clients:
 
ATM VPC/VCC n:1 cell mode     To be assigned XX-X1
ATM VPC 1:1 cell mode         To be assigned XX-X2
ATM VCC 1:1 cell mode         To be assigned XX-X3
AAL5 CPCS-SDU mode            To be assigned XX-X4
AAL4 PDU frame mode           To be assigned XX-X5
FR 1:1                        To be assigned XX-X6
FR port                       To be assigned XX-X7
HDLC                          To be assigned XX-X9
PPP                           To be assigned XX-X8
SDH VC11                      To be assigned XX-X10
SDH VC12                      To be assigned XX-X11
SDH VC3                       To be assigned XX-X12
SDH VC4                       To be assigned XX-X13
 
The encapsulation into an EVC will use the PWE3 encapsulations as specified
in the RFCs. The TYPE field with the EtherType will then be added on top of
the Control Word. And on top of the TYPE field we will get the SA and DA
fields.
 
---------------------
|       DA          |
---------------------
|       SA          |
---------------------
|      TYPE         |
---------------------
|       CW plus     |
|   remainder of    |
|   PWE3 packet     |
---------------------
 
Refer to the attached pdf file for the PWE3 frame formats extended with
Ethernet TYPE field.
 
Regards,
Maarten

  _____  

From: Shahram Davari [mailto:[e-mail]] 
Sent: vrijdag 13 maart 2009 13:50
To: [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: RE: [mpls-tp] MPLS-TP protocol/payload type usage in
OAMExtractionProcess


Hi Neil,
 
I think what Martin is saying is this:
 
Assume there are two network providers, one is using MPLS-TP and the other
using PBB-TE as transport.  And a service provider wants to provide a
service (say IP service or ATM service) across these two network providers.
If both of these network providers first map their services over Ethernet
and then over their transport technology, then Ethernet could be a unifying
layer and these two networks could interwork without any problem. However,
if one maps the service to MPLS-TP and the other maps the same service to
PBB-TE, they can't interwork (complex interworking) because there is no
shared layer.
 
But I have another suggestions: 
 
Assuming that PW or any other method is used for mapping a service to
MPLs-TP, let's make sure the same mapping method (PW or others) are used by
IEEE for PBB -TE or other Ethernet based transports.
 
Bets regards,
Shahram 
 
From: [e-mail] [mailto:[e-mail]] On Behalf
Of [e-mail]
Sent: March-13-09 5:07 AM
To: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [mpls-tp] MPLS-TP protocol/payload type usage in OAM
ExtractionProcess
 
And good morning to you too Maarten.......
 

  _____  

From: Maarten Vissers [mailto:[e-mail]] 
Sent: 13 March 2009 07:39
To: Harrison,N,Neil,CXM R; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: RE: [mpls-tp] MPLS-TP protocol/payload type usage in OAM
ExtractionProcess
Hello Neil,
 
Good morning.
Thank you for responding.
 

  _____  

From: [e-mail] [mailto:[e-mail]] 
Sent: vrijdag 13 maart 2009 7:33
To: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: RE: [mpls-tp] MPLS-TP protocol/payload type usage in OAM
ExtractionProcess
Nice pictures Maarten, but all of this is not required:
 
-    there cannot be MS-PWs in MPLS-TP....MS-PWs represent a co-ps layer
network above MPLS-TP.  If this is true then MPLS-TP has failed as a
transport network. 
 
[mv] As far as I understand the MPLS-TP requirements, there is a "transport
service layer" in MPLS-TP. Do you agree? 
NH=> I have no idea what this term means.   MPLS-TP is supposed to be a
transport network....just like a load of others are.
 
[mv] It seems that we are struggling with the name of this "transport
service layer". If I understand your persistent comment well, then you do
not like to refer to this transport service layer as the "PW" layer. 
NH=> Let's be very clear here.  MPLS-TP is supposed to be a transport
network itself...this is whole purpose of the exercise.  PWs started life as
an adaptation to get around architectural flaws in MPLS.  Unfortunately,
PWE3 decided several years ago to make PWs multi-hop...and as soon as they
did that there was a major shift in what PWs represented....they were no
longer adaptation but a full-blown co-ps layer network.  This was a bad
mistake, and I repeatedly warned PWE3 not to do this.  
 
The architectural flaws in MPLS that spawned PWs *must* be corrected in
MPLS-TP...else, quite simply, it cannot be a transport network.  I do think
most folks understand this.  So, we cannot have MS-PWs in MPLS-TP...unless
we want MPLS-TP to look very silly.
 
 
  At some point in time I got the impression that you would like to deploy a
second instance of the MPLS-TP LSP as transport service layer. 
NH=> We are supposed to designing MPLS-TP to be a non top-of-stack co-ps
mode transport network, so all it can do is create higher layer network
topology....nothing unusual here, we have lots of technologies that provide
such a role, esp in the co-cs mode.
  
When I look at what is present in a number of networks today, then I find
the use of an Ethernet VLAN layer as transport service layer in existing
MPLS networks. 
NH=> I don't understand why you home-in on VLANs.  Ethernet in-total is used
as a server to MPLS.....MPLS does not have a physical/section layer
specification and so must run over a technology that does, ie can modulate
an EM wave on radio/optics/metrallic media.....which actually is not a great
place to start for a technology that aspires to be a *transport* network if
you think about it. 
 
  This use of an Ethernet VLAN layer as transport service layer would be
aligned MEF's MEN model in which the EVC (i.e. Ethernet VLAN) is providing
the transport service layer role.  This EVC layer is then supported by the
MEN Transport layer, which could be another Ethernet VLAN instance, or MPLS
LSP or MPLS-TP LSP or PBB-TE TESI, or ...,  
NH=> I am not sure what your point is here.  There is no such thing as 'VLAN
layer networks'....there are 'Ethernet layer networks' however. 
 
-    there must be no interworking of Ethernet and MPLS-TP..... 
 
[mv] if we agree to deploy the EVC layer as transport service layer in
MPLS-TP there will indeed be no interworking necessary at the transport
service layer of a hybrid ethernet and mpls-tp packet transport network. 
 
[mv] if we however agree to define a "MS-PW" or "LSP" based transport
service layer in the MPLS-TP stack to support p2p and p2mp services, then
there must be interworking between p2p/p2mp VLANs in the ethernet domains
and those p2p/p2mp "MS-PW"/"LSP"s in the MPLS-TP domain if we want to offer
at least p2p and p2mp services to customers in such hybrid packet transport
network. 
NH=> I disagree with you.  There is no need whatsover to peer interwork
Ethernet with MPLS or MPLS-TP or (heaven forbid) a PW layer network.  The
rule is very simple:  If not top-of-stack then don't peer interwork.  And
that is really all there is to be said on the matter.   If you don't respect
this all you will do is create lots of work and costs doing protocol
conversion between all the DP/CP functional components of technologies that
have no need to do this.  I do not want to see our industry expending
effort/money on things that are simply not necessary.
 
  As we discussed last month in London, the p2p/p2mp VLAN and p2p/p2mp
"MS-PW"/"LSP" reside in different partitions within the same "transport
service layer".  
NH=> No they don't....this is stuff you have made up.  I don't think you
listened to what I and Andy said to you.  These are things you think are
sensible because they can be done.  But like merging in the co-ps mode, just
because one can do something does not make it a sensible/worthwhile thing to
do...there is a whole raft of crazy things I could dream up for us to work
on.  The bottom line is what I stated above....if not top-of-stack then
forget interworking as peers...esp if the networks belong to different
modes!.....it really is that simple.  We cannot afford to be throwing money
away on unnecessary protocol conversion work.
 
 In most cases so far partitions in one layer deploy the same technology. In
this case, partitions in the transport service layer deploy different
technologies, but the information carried in both cases is the same.
 
 this is more than OAM, though even that is not the same, eg there must be
no FDI/AIS in a cl-ps network like Ethernet, which is why IEEE threw this
out of .1ag.   
 
[mv] IEEE left out AIS because in a STP controlled domain restoration of the
VLANs is an implicit feature. This implies that generation of AIS at the end
of a failed link has to be stopped within a few second'; i.e. as soon as the
VLAN's registration on this port is removed. 
NH=> IEEE threw out AIS/FDI because it makes no sense for cl-ps networks.
If you think it's such a great idea then go and try and convince IETF to
include it in IP and see what reaction you get.  And here is something else
that may shock you....a couple of years ago Andy (Reid) and I were
discussing this whole notion of AIS/FDI in the 3 networks modes.  We
concluded that it would be better even if the co-ps mode did not have
AIS/FDI, not just the cl-ps mode (which is obvious).  AIS/FDI is only truly
sensible in the co-cs mode.  I can explain why but this now off topic....I
only mention this to illustrate that one cannot have identical functional
specifications for the 3 modes (and this is more than OAM)....it is their
differences that are the important bits.
 
[mv] ETH-AIS is an important feature in ethernet transport networks that do
not have end-to-end restoration active. ETH OAM checks the status and
performance of the VLAN. VLANs in a transport network are set up under
control of network management with or without the help of a GMPLS control
plane. Such VLANs have a fixed connectivity, similar as a bidirectional
point-to-multipoint connection. The ETH OAM checks this fixed connectivity;
i.e. the connection-oriented part of the VLAN is checked (ETH OAM does not
check the connectionless part (i.e. filtering rules) pro-actively; it is
however capable to check the connectionless part on-demand via its LTM/LTR
OAM). If such VLAN is interrupted and not restored, ETH-AIS must be
generated to prevent ETH LOC alarms to be raised from the downstream MEP
functions.
NH=> I don't agree with your view of networking expressed above.
 
 There is major DP/CP functional mismatch between MPLS-TP and Ethernet so
there is no way I can agree to interworking these as peers.  And in any case
neither is a top-of-stack network so any interworking would be a wasted
exercise anyway. 
 
[mv] Ethernet VLAN deployment in packet transport networks is under control
of network management (possibly with the help of a GMPLS control plane).
Ethernet VLANs are Traffic Engineered. 
Such traffic engineered p2p VLANs and p2mp VLANs deploy just a Broadcast
Forwarding Rule and **no** Unicast/Multicast Filtering Rules. Traffic
engineered MPLS-TP "MS-PW"/"LSP" transport service layer connections also
deploy a Broadcast Forwarding Rule and **no** Unicast/Multicast Filtering
Rules. Both transport entities are traffic engineered. It is as such
possible to interwork these two transport service layer transport entities
without too much problems if we make sure that the OAM PDU formats are very
common.
NH=> I do not agree with this.
 
[mv] But if we agree to deploy the EVC as transport service layer in
MPLS-TP, then we do not need to create interworking between two
technological different partitions in the transport service layer, as there
will be just a single technology deployed in all partitions.
 
[mv] Deployment of the EVC as transport service layer technology however
requires that the EVC must support more then only Ethernet and TDM clients.
I.e. must support also ATM, FR, PPP, etc clients as defined in PWE3. To
support those other PWE3 clients, we need to get a number of EtherType
values, one for each client. 
NH=> You may not be aware, but there is now an Ethetype for GFP...its 891F.
Now you can use UPI codepoints for legacy technologies without bothering
IEEE for an Ethetype for every technology that does not have one....but if
you want to go and get then fine.
 
regards, Neil
 
  I will upload later a set of slides presenting those PWe3 mappings into an
EVC, inluding a list of EtherTypes that would be required to support this.
 
Regards,
Maarten
 
regards, Neil
 

  _____  

From: [e-mail] [mailto:[e-mail]] On Behalf
Of Maarten Vissers
Sent: 12 March 2009 22:29
To: 'Malcolm Betts'
Cc: [e-mail]; [e-mail]
Subject: [mpls-tp] MPLS-TP protocol/payload type usage in OAM
ExtractionProcess
Malcolm,
 
You asked the question:
> The question is do differences create a significant risk of undetected
faults due to the different
> treatment of OAM and the data path in either the originating or
terminating processes.
 
The packet formats of the LSP_CI, PW_CI and VPLS_CI are inspected by the so
called "OAM Extraction Process"
in the termination and adaptation functions. Refer to G.8021 and G.8121 for
examples of such OAM Extraction Processes.
For the MPLS-TP case and assuming the packet formats below, these OAM
Extraction Processes would inspect the top 
few rows of those packets to determine the type of payload/protocol (e.g.
OAM CCM) that is carried. 
This can be illustrated as follows for the LSP OAM, MS-PW OAM and VPLS OAM:
 
LSP OAM with GAL:
-----------------------------

 
LSP OAM without GAL:
----------------------------------

 
MS-PW OAM:
--------------------
 

 
VPLS (i.e. ETH) OAM:
--------------------------------
 

 
 
I hope you understand that all packets are treated the same way in a
termination or adaptation OAM Extraction process. All (OAM and DATA) packets
are inspected on the six, four or two fields and the values in those fields
determine if a packet contains OAM or DATA.
 
The GAL is really not required as its information is a copy of the
information in the S-bit of the label and the first 4-bit of the ACH.
 
Regards,
Maarten
 
 
 

  _____  

From: [e-mail] [mailto:[e-mail]] On Behalf
Of Maarten Vissers
Sent: dinsdag 10 maart 2009 18:16
To: 'Malcolm Betts'; [e-mail]; 'Loa Andersson'
Cc: [e-mail]; [e-mail]
Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for
MPLS(-TP)overMPLS(-TP)
Malcolm,

The forwarded information is the MPLS-TP LSP Characteristic Information
(LSP_CI) and the MPLS-TP MS-PW Characteristic Information (PW_CI). 
The GAL and ACH fields are both part of the LSP_CI and the ACH is part of
the PW_CI traffic units. 
As per G.8110, the S-bit and TTL-bits or the label stack entry header are
also part of the CI and hide the GAL and ACH fields during forwarding.
The S-bit provides the first subfield of the MPLS-TP Payload Type.
LSP_CI packet formats are illustrated below:


 
PW_CI and VPLS_CI packet formats are illustrated below:

Regards,
Maarten


-----Original Message-----
From: Malcolm Betts [mailto:[e-mail]]
Sent: dinsdag 10 maart 2009 16:15
To: [e-mail]; Loa Andersson
Cc: [e-mail]; [e-mail]
Subject: RE: [mpls-tp] Clarifying MPLS-TP requirements for
MPLS(-TP)overMPLS(-TP)

First a minor digression to explain my paranoia on this issue ;)

In high availability networks (like the Transport network) the "killer"
faults are the ones that you do not detect.  The normal conversation about
these faults is "well that should not have happened...." but "stuff
happens".  I am not an expert on MPLS equipment implementations or the
control protocols so I am seeking expert guidance.

So with that mind set:

I agree that only the top label is use forwarding so no problems "in the
network".  However at the node that originates an terminates the MPLS-TP
path we do see a difference in the pdu structure:
For traffic the pdu is:  {label X S=1}{Payload} For OAM the pdu is:  {label
X S=0}{GAL S=1}{ACh; Payload}

Clearly these are different label stacks both at the originating and
terminating nodes.  The question is do differences create a significant risk
of undetected faults due to the different treatment of OAM and the data path
in either the originating or terminating processes.  Remember the more
successful MPLS-TP the greater the chance that a corner case fault will
appear.....

The "uniform stack" for MPLS-TP would be: {label X S=0}{GAL S=1}{ACh*;
Payload} where the ACh* code point would also include the client payload
types as well as OAM, MCC, DCC etc.


Malcolm Betts
Nortel Networks
Phone: [phone] (ESN 393)
email: [e-mail]

-----Original Message-----
From: Stewart Bryant [mailto:[e-mail]]
Sent: Monday, March 09, 2009 11:08 AM
To: Loa Andersson
Cc: Betts, Malcolm (CAR:X632); [e-mail]; [e-mail]
Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP)
overMPLS(-TP)

Loa Andersson wrote:
> Malcolm,
>
> Malcolm Betts wrote:
>> Ben, see in line below - I have snipped some text for clarity:
> <snipped even more - Loa>
>
>>
>> I think that the requirements draft should indicate that all frames,
>> i.e. client data, OAM, SCC, MCC, etc MUST receive identical treatment

>> in the data plane and therefore MUST use the same header structure.
>
> all packets with the same label on top will get the same treatment,
> given that the TC field is the same, won't they? Is this what you mean

> by "header structure" or did I miss something
>
> /Loa
>>
>
>

There is a bunch of confusion about what happens in MPLS networks.

In transport networks - set up statically or via GMPLS only the top label
effects the path (although TC effects the queuing).

There are no standard methods for looking at any other label and in any case
this is only done in networks where the path is chosen by an IGP.

If we always use a PW then the requirement for client data, OAM, SCC, MCC to
receive identical treatment in the path to the PE occurs because the label
stack is identical.

The only case where the label stack will be different is when we are
carrying an LSP OAM in which case the GAL needs to be present.


Stewart