Subject: [PWOT] RE: draft-danenberg-sonet-ces-mpls-mib-00.txt

From: Heiles Juergen <[email-masked]>
Date: Fri, 2 Mar 2001 16:52:31 +0100

It is interesting to see the increased interest in the supervision features of the "expensive, complicated, ..." TDM=Sonet/SDH system as soon as it is going carrier class.
By the way Sonet/SDH offers already a feature for supervison of a sub-network connections of a STS-SPE (VC). It is called tandem connection monitoring TCM. It basically determines the failure/bit error status at the start of the sub-network connection, transports it via an overhead byte (N1) to the end of the sub-network connection and compares it with the status there (bit -errors at start - bit erros at end= bit errors of sub-network connection). In additon it provides its own trace for conenctivity supervision.
In any case supervision at the MPLS layer is of interest (see the discussion on MPLS OAM), which however should be independent of the client signals.

Concerning CEM over MPLS for CBR signals like a STS-SPE/VC in general I share some of the doubts expressed in a previous mail, specifically for clock jitter and wander. The MPLS transport could result in excessive pointer justification of the STS-SPE or VT outside the Sonet/SDH specifications.
 
Regards

Juergen 

> -----Original Message-----
> From:	Dave Danenberg [SMTP:[email-masked]]
> Sent:	Friday, March 02, 2001 4:06 PM
> To:	David Zelig; Jim Boyle
> Cc:	[email-masked]; [email-masked]; Thomas D. Nadeau; Andrew G. Malis (E-mail); tom k. johnson
> Subject:	RE: draft-danenberg-sonet-ces-mpls-mib-00.txt
> 
> Dave/Jim,
> 
> We've considered your input on CEM statistics reporting and certainly
> agree that they are good recommendations. We consider this an open
> issue. But instead of immediately trying to solve it via the email list,
> we're thinking of raising it as an issue at the PWOT session at the
> upcoming IETF meeting. Then we'll gather and consider any more input,
> before distributing a proposal for better CEM stats.
> 
> It looks like others are interested in TDM-like stats in the IP world.
> Did you see the thread on MPLS email under the subject heading "RE:
> Standards for IP stats collection? (corrected)" ?
> 
> -- Dave Danenberg
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Dave
> Danenberg
> Sent: Wednesday, February 28, 2001 9:16 AM
> To: David Zelig; Thomas D. Nadeau; Jim Boyle; Andrew G. Malis (E-mail)
> Cc: [email-masked]; tom k. johnson
> Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt
> 
> 
> David Zelig, Jim, Tom, Andy,
> 
> Deriving SONET-like statistics from the CEM function is worth exploring
> further. As David Zelig points out, the CEM operation at the ends of the
> tunnel can monitor the path's B3 (BIP) byte. Although it may be tempting
> to piggyback on existing functionality (B3), this technique would not be
> able to easily discern between the errors introduced before the path
> reached the CEM (Ac-A in the example) and the errors introduced within
> the tunnel (A-Z). The CEM operation (at A) could regenerate B3, but that
> would violate the integrity of the path's own error statistics. So I
> think the way to look at this problem is by thinking of the CEM
> operation as what it really is - an emulated SONET 'line' carrying the
> path as its payload. As a 'line', the CEM could generate and terminate
> its own BIP. This BIP, could then be used to create the same quality and
> format of statistics as folks expect from SONET.
> 
> For CEM to support its own payload BIP, a new field would be required in
> the CEM header. So this needs to carefully considered. If we were to do
> this, we also need to decide if the CEM payload BIP should be calculated
> on path or on packet delineations (i.e., calculated on the previous path
> frame just as B3 does, or on the CEM header to end of packet).
> 
> (We'll forward this issue to the PWOT email list)
> 
> Dave Danenberg
> 
> 
> -----Original Message-----
> From: David Zelig [mailto:[email-masked]]
> Sent: Wednesday, February 28, 2001 2:11 AM
> To: 'Thomas D. Nadeau'; Dave Danenberg; Jim Boyle
> Cc: [email-masked]
> Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt
> 
> 
> Tom, Dave and Jim,
> 
> In order to detect payload defects at the STS level there are BIP
> checking
> on the path overhead. If an operator want to check errors generated by
> the
> CEM operation it may be simpler (and more understood) to monitor the B3
> byte
> for errors in both ends of the tunnel. This can be done on the example
> below
> on the interface on the IP edge device.
> 
> It is very hard to manipulate CEM errors to payload errors, and if the
> customer bought SONET service (and sign on SONET SLA) the PM should be
> on
> SONET "language" and measured at the SONET level.
> 
> Sure we must cover all potential CEM errors in order to enable detecting
> the
> cause of the errors, especially for the case of problems caused by
> mis-configuration.I think that we need to deliver interval data for all
> PM
> related errors, and for events count.
> 
> David
> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Wednesday, February 28, 2001 5:49 AM
> To: Dave Danenberg; Jim Boyle
> Cc: [email-masked]
> Subject: RE: draft-danenberg-sonet-ces-mpls-mib-00.txt
> 
> 
> At 08:02 PM 2/27/2001 -0500, Dave Danenberg wrote:
> >Jim,
> >
> >Thanx for your input. It sounds like you'd like to see the same sort of
> >statistical information from the emulated SONET that folks are
> >accustomed to seeing from SONET networking equipment. I like that too
> >(from years of developing telecomm equipment for service providers).
> >
> >Although I was considering second order counts (errored seconds) or
> >trends (15 minute, 24 hour interval data), I decided to start with just
> >simple counts - and see what folks think.
> >
> >Andy's CEM does not detect errors over the CEM payload, but it does
> >detect errors within the CEM header (the CEM MIB counts them with
> >mplsCemVcPerfCrctHdrErrors and mplsCemVcPerfUncrctHdrErrors). Perhaps
> >CEM header error rates can be extrapolated to indicate payload errors
> >rates. Due to the nature of CEM, other types of errors are detectable
> >(buffer errors, missing packets, etc). Assuming CEM equipment can
> >process this raw info into some nice statistics, another set of objects
> >can be added to the CEM MIB.
> >
> >So, I'd like to include the type of statistical info you suggest as
> well
> >as your "reason for last down" idea. Would you like to see interval
> data
> >as well?
> >
> >What do you think Tom? If you agree, I can come up with another set of
> >objects and send it to Jim (and mpls email) for comment.
> 
>          Yes, as I mentioned earlier, I think these things are a
> good idea. Lets work on them and get our ideas back out to the
> list shortly.
> 
>          --Tom
> 
> 
> 
> 
> >Dave
> >
> >
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]]On Behalf Of Jim
> Boyle
> >Sent: Tuesday, February 27, 2001 2:24 PM
> >To: Thomas D. Nadeau
> >Cc: [email-masked]
> >Subject: Re: draft-danenberg-sonet-ces-mpls-mib-00.txt
> >
> >
> >
> >pretend you are a service provider, a customer calls in and says he's
> >seeing errors on his service (in particular, bip violalations in POH).
> >
> >He is directly connected to your network via port A.
> >On the far end, he connects to a clec, which hands it off to you at
> port
> >Z.  He connects to a CLEC adm on port Z'.  His path terminating
> >equipment
> >(maybe a router) is port Ac, and Zc, such that the service looks like:
> >
> >Ac-A-[IP]-Z-CLEC-Z'-Zc
> >
> >Looking at lines Ac-A and Z-CLEC shows clean lines.
> >
> >How does the operator determine if his IP network is to blame, or the
> >CLECs network is to blame?
> >
> >i'd recomend a few things:
> >
> >o) Andy's draft should have some sort of way to determine if there are
> >bit> 
> >errors hapenning across t> he IP network that affect the service
> >payload.  This would provide the same sort of delineation of where a
> >problem is occuring by looking at LOHs in more traditional transport
> >network.
> >
> >o) your mib should include analogues to the SONET mib, such as bip-8
> >violations, errored seconds, etc... (working off memory here).
> >
> >o) addition of a "reason for last down" might be nice.
> >
> >This way, when you, as the service provider, replies that "it's not our
> >problem, must be the clec", they can say at least go look at it later
> to
> >see if they were telling the truth.
> >
> >As usual, excellent attention paid to the configuration aspects.
> >
> >regards,
> >
> >Jim
> >
> >
> >On Fri, 23 Feb 2001, Thomas D. Nadeau wrote:
> >
> > >
> > >       Hi,
> > >
> > >       FYI a new MIB for managing SONET/SDH Circuit Emulation
> > > Service Over MPLS has been posted. It should be available
> > > shortly via the IETF's web site. In the meantime, it is available
> > > at the following web/ftp link. As usual, comments are welcome.
> > >
> > >
> >ftp://[email-masked]/ftp/tnadeau/draft-danenberg-sonet-ces
> -
> >mpls-mib-00.txt
> > >
> > >       --Tom
> > >

_______________________________________________
pwot mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/pwot

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 02 Mar 2001 17:04:19 -0500

Heiles,

>Concerning CEM over MPLS for CBR signals like a STS-SPE/VC in general I 
>share some of the doubts expressed in a previous mail, specifically for 
>clock jitter and wander. The MPLS transport could result in excessive 
>pointer justification of the STS-SPE or VT outside the Sonet/SDH 
>specifications.

As you have probably noticed, one of the areas that still needs more 
fleshing out in draft-malis-sonet-ces-mpls-03.txt are the underlying QoS 
requirements for the MPLS transport.  Of course, the QoS you can get is 
dependent on the capabilities of the MPLS LSRs - best effort forwarding 
only is obviously insufficient.  The more interesting question is what IS 
sufficient in the transport network to be able to meet the generally 
accepted requirements for bit error rates, clock jitter and wander, etc., 
and how large do the jitter buffers need to be at the receiver?

Of course, using the EF codepoint in either an E-LSP or L-LSP is the 
obvious starting point, but that will still be dependent on the network 
operators allocating sufficient resources for EF traffic in their networks 
so that the emulated SONET circuits perform adequately.  It may end up 
being an iterative process, at least at first, in order to get it right.

Regarding jitter buffers, most people I've discussed this with seem to 
think that about 10-15 ms worth of buffering should be more than sufficient.

I appreciate any other thoughts you may have.

Cheers,
Andy