Subject: Re: Liaison from MPLS Forum to PWE3

From: [email-masked]
Date: Thu, 17 Apr 2003 17:13:24 +0100

Dear Tom,

Here is my response to your recent liaison request to the PWE3 Forum 
regarding the document "TDM Transport over MPLS using AAL1 Implementation 
Agreement".

Overall, the document is a commendable approach to carrying TDM over an 
MPLS network, based on a mature, pre-existing technology (i.e. AAL1). A 
similar proposal, draft-anavi-tdmoip, has been before the IETF for some 
time, and extensively discussed on the list.

My main comment on the document is that although it describes a means of 
carrying TDM over an MPLS network, it does not clearly show what quality 
of TDM service will result from its use. While for low-cost, customer 
equipment performing a "cheap and cheerful" toll bypass type application 
the absolute level of quality may not be important, the fidelity of the 
service is important if this technology is ever to gain acceptance as a 
carrier-operated technology. Therefore I would like to see more details on 
the quality of the TDM service one can expect, and the performance of the 
underlying MPLS network required to achieve it.

I have various comments about specific parts of the text which are 
outlined below. These include several recommendations for changes.  Some 
of the points outlined below are covered in the other TDM drafts currently 
before the IETF, particularly draft-johnson-pwe3-tdm and 
draft-vainshtein-cesopsn. Since these drafts, along with 
draft-anavi-tdmoip (the companion draft to the MPLS Forum document), are 
still under discussion in the IETF, I would recommend that MPLS Forum 
members join in the debate to find a common solution, rather than run the 
risk of different, non-interoperable standards being developed in various 
separate organisations.

Regards,
Tim

Tim Frost,
System Architect,
Zarlink Semiconductor
----------------------------------------------------------
Address: Tamerton Road, Roborough, Plymouth, PL6 7BQ, U.K.
Tel.:   +44 1752 693840
Mobile: +44 7720 700405
Fax.:   +44 1752 693743
Email:  [email-masked]
----------------------------------------------------------

The specific comments I have on the document are outlined below.

Section 2, TDM and MPLS Network Interworking Requirements
4. Timing
"May" seems very weak for something so important to TDM networks. If there 
is no method for clock reconstruction, then the use of the scheme is 
restricted to scenarios where either the TDM devices at each end or the PE 
devices at each edge share a common clock, or have access to a PRS 
traceable reference. Essentially this means CO to CO scenario, which is 
small subset of the possible applications of this type of device.
The lack of clock reconstruction in other scenarios would lead to a 
serious degradation in quality, expressed in frequent uncontrolled TDM 
frame slips.
I recommend that this is at least a "should", i.e. a strong 
recommendation, not merely a permission.

6. Interworking
Given the documents stated purpose "to define the network interworking 
between the TDM circuits (nx64kbps, T1, E1, T3, E3) over MPLS Label 
Switched Paths", I question whether the ability to inter-work with ATM 
AAL1 services is a requirement, or merely a desirable feature of the 
chosen implementation.
Inter-working with AAL1 is clearly an area where a vendor could add value 
to their equipment, but it is not necessary to achieve the stated purpose.

Section 4, TDM-MPLS Payload

General comments on payload format:
1. In unstructured mode, there is no requirement to carry the protected 
sequence number in every AAL1 sub-frame. This serves no purpose, and is 
therefore wasted bandwidth.
2. In structured mode, the structure pointer is buried within the payload. 
This makes is awkward for an implementation to find the pointer, 
particularly since it may be in different places depending on the number 
of sub-frames in each packet.
In general, I recommend that any control information such as a pointer is 
placed in the header where it is in a consistent position and may be 
easily found and processed. This pointer would also be more resistant to 
packet loss since it is transmitted with every packet (or at least every 
packet containing a structure start), not every eight sub-frames.

The TDM-MPLS Agreement also inherits the following undesirable properties 
of AAL1:
1. For nx64kbps, the granularity of delay introduced by the packet 
formation process may be high, particularly for small values of n. This is 
because the sub-frames need to be filled with payload. The use of 
partially filled sub-frames is a rather inefficient means of keeping the 
packet formation delay low.
There is no need in an MPLS packet network to have packets of a fixed size 
as in ATM, therefore the packet size could be tuned to a better compromise 
between efficiency and latency.
2. The carriage of CAS is handled by a sub-structure, which may span 
across cell boundaries, or be found buried in the middle of a cell. With a 
fixed cell size, this was an unavoidable complication. With an MPLS packet 
network permitting variable packet sizes, this is no longer true. Since 
the CAS sub-structure will be processed separately from the data, it is 
desirable to place it in an easily accessible location within the packet, 
e.g. a header extension, or appended to the end of the data section with a 
pointer in the header to its location.

Service Inter-working with ATM
1.The document recommends checking the contents of the CRC and P bits in 
the protected sequence number when interworking with ATM. As the cells 
come in from the ATM network, I agree this checking must occur. However, 
in common with other layer 2 pseudo-wire schemes, these bits should then 
be discarded (e.g. discarding of the Ethernet FCS in 
draft-ietf-pwe3-ethernet-encap, or the Frame Relay FCS in 
draft-ietf-pwe3-frame-relay). For inter-working in the opposite direction, 
these bits can be generated on entry to the ATM network.
This is consistent with the suggestions on payload format given above.
2. The document describes data-plane interworking with AAL1 - i.e. 
translation of AAL1 sub-frames into TDM-MPLS packets and vice versa. It 
doesn't cover control-plane or OAM inter-working.  Therefore it would 
appear to me that the document doesn't describe everything that would need 
to be done to provide full service interworking between AAL1 and TDM-MPLS. 
I am not sufficiently expert in ATM to know how much of an omission this 
is.

The addressing of the above points would simplify any implementation of a 
TDM-MPLS interworking function. The implementation agreement as it stands 
strongly favours the inclusion of an AAL1 SAR function as an intermediate 
step, even when inter-working with ATM is not required. It would be better 
to structure the agreement such that the AAL1 SAR function would be 
required ONLY when inter-working with ATM is required.

Section 5, General Requirements

Apart from a vague suggestion that the MPLS network support quality of 
service, there are no requirements on the MPLS network itself. I envisage 
a section describing a service level specification that would allow the 
TDM-MPLS service to achieve a stated level of quality. For example, what 
service level specification on the MPLS network would I require in order 
to operate a TDM-MPLS service that meets the existing TDM standards?
This would include parameters such as edge to edge packet delay and packet 
delay variation, packet loss rates, packet error rates and so on.

Section 7, Clock Recovery

Requirements on clock recovery are weak.
The document describes a "whole network" scenario, where the TDM-MPLS is 
used to replace the TDM infrastructure. Timing recovery is described as 
mandatory in this application, yet the quality of the timing recovery is 
only "recommended" to be in conformance with the relevant ITU-T standards. 
For this type of scenario, meeting the ITU-T standards is mandatory, or no 
carrier will ever deploy this technology. It is also a strange omission 
given that the authors have already noted that the use of time standards 
less accurate than Stratum 3 is not recommended.

The requirement "The regenerated clock SHOULD conform to ITU-T 
recommendations G.823 for E1 and G.824 for T1 trunks" doesn't specify 
which type of interface it should conform to, e.g. traffic interface, 
synchronisation interface, reference interface.

The implementation agreement does not contain any information about clock 
recovery, how it should be carried out, or how it may be guaranteed to 
meet the standards quoted. This may be because it is part of a particular 
vendor's value add, but consideration should be given as to whether any 
means of guaranteeing accuracy should be included as part of this 
implementation agreement, otherwise it may hinder inter-operability 
between different vendors' equipment.

"Walsh, Thomas D (Tom)" <[email-masked]>
Sent by: [email-masked]
28-Feb-2003 06:20 PM

        To:     "[email-masked]'" <[email-masked]>
        cc: 
        Subject:        [PWE3] Liaison from MPLS Forum to PWE3

To: IETF PWE3 working group

From:  MPLS Forum

The MPLS Forum Technical Committee has been discussing the transport of 
TDM
over MPLS networks, and we now have a draft of the "TDM Transport over 
MPLS
using AAL1 Implementation Agreement" reaching its final stages.  Since the
PWE3 working group has also been working on this issue, we would like to
invite comments from the WG before progressing this text to final ballot.
For this purpose, we have placed the straw ballot text of the 
Implementation
Agreement in the public area of our web site, at
http://www.mplsforum.org/tech/mpls2003.036.01.pdf .

We have temporarily delayed the advancement of our Implementation 
Agreement
in order to avoid conflicts between the specifications.  Alignment with 
IETF
RFCs is a key objective for implementation agreements reached in the MPLS
Forum.

However, there is also significant interest in the MPLS Forum to bring 
this
work to a conclusion.  The MPLS Forum encourages the PWE3 WG to reach a
timely agreement on this topic so that our two bodies can produce an 
aligned
solution.

Comments are invited from individual IETF and IESG participants, the 
working
group as a body, and the IESG as a body.  We will look for comments and
discussion on the PWE3 mailing list.

Best regards,

Andy Malis
MPLS Forum President

Tom Walsh
MPLS Forum 
External Relations
_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: [email-masked]
Date: Thu, 17 Apr 2003 18:20:04 +0100

Tim....I am finding it hard to appreciate the sentiments of your comments
(which BTW I agree with) in the context of what I see unfurling in PWE3.
Please see below.

regards, Neil

[email-masked] wrote 17 April 2003 17:13
> MPLS network, based on a mature, pre-existing technology 
> (i.e. AAL1).
NH=> Agreed.

> A similar proposal, draft-anavi-tdmoip, has been before the 
> IETF for some 

> of TDM service will result from its use.
NH=> The performance experienced by a client layer network (TDM here) will
be *inherited* (not necessarily linearly for some metrics) from *all* layers
below this to the duct.  Let's just take the immediately lower MPLS server
layer case however.  The implication of this statement is that the MPLS
layer must therefore be just as well defined in this sense....I don't think
is the case.  Now what about an IP server layer?  The fact is the two cases
are not (and indeed have no need to be) the same....you can try and force
such behaviour, but I really see no benefit.  Horses for courses......use
the 3 basic networks modes (of cnls, co pkt-sw and co cct-sw(L1)) wisely
since they solve different problems and *all* are needed by carriers.

> While for low-cost, customer 
> carrier-operated technology.
NH=> Just how does one define (the requirements of) 'carrier-operated
technology'?  Again, I can see that X/IP and X/MPLS can give different
results (and very validly so).....one of these *could* be classed as
carrier-grade whilst the other may not for a *given* client type.  For
example TDMoverMPLS is different from TDMoverIP IMO.  I would have thought a
key/general carrier-grade client/server requirements ought to be functional
client/server layer independence..........which includes simple, yet must be
robust/consistent, fault-management of both the client and the server layers
{dare I say Y.1711 for MPLS?  Outside of Y.1711 there are no defects defined
for MPLS.....and if we dont't have these then how can we start to define
availability?....and if we can't do this then how can we even start to
discuss QoS?....and if this is not defined for MPLS then how can we
seriously expect to ask others to define the performance delivered to the
clients of MPLS?  There is a logical sequence here.}

Get the above right and we don't need (and certainly don't want) unecessary
functions in the 'in-between' layer between client layer and server layer
(like OAM for PWS for goodness sake!).....this is creating more stuff
(=problems/costs) for carriers to manage.  Keep it simple/independent....and
differentiate X/IP from X/MPLS....there is no reason (outside dogma) to
force them to be the same.

> Therefore I would like to see 
> more details on 
NH=> Agreed Tim....my very point above.....this starts with defects, moves
through availability and then (and only then) defines QoS.  And these
considerations are different in the X/IP or X/MPLS cases.
<snipped>