The MPLS-OPS Archive

[Mat.e.Hobbis@alcatel.co.uk]

All,

There are vendors out there who provide TDM over IP style products, see RAD
etc. The TDM timing issues must be handled at the adaptation layer, as they
are in ATM with AAL1 ACR/SRTS etc. The receiving adaptation layer will, by
necessity, include a "playout buffer" which is used to smooth the delay
variation introduced by the packet network. The biggest problem that an IP
network is likely to face is that of clock distribution when large amounts
of TDM 'legacy' services have to be supported ;-)

Transport of the resulting TDM/RTS/UDP/IP/x or TDM/UDP/IP/x stream is
accomplished via the EF class of service. If this is mapped to an MPLS LSP
than the LSP should have resources reserved via the RSVP-TE protocol. All
component flows on the LSP must be CAC'ed into it to ensure that it has
enough resources. In terms of buffering it depends how you describe the
traffic and the flexibility of the routing/switching platform. As packets
will be generated at a rate of 1 every X milliseconds and each frame will
be of size Y bytes the bit rate should be easily calculated. PIR = CIR =
calculated bit rate, and burst size would generally be set at a low value
packets depending on the contention ratio in the core.

Regards,

Mat.


Mathew Hobbis BSc(hons) MSc
Solutions Architect.
Alcatel.

e-mail : mat.e.hobbis@alcatel.co.uk









                                                                                                                                       
                      "Khan, Amjad"                                                                                                    
                      <akhan@flagteleco        To:       "'Spice Sylvia'" <falsesylvia@yahoo.co.uk>, "McCallum, Robert"                
                      m.com>                    <robert.mccallum@thus.net>, Luis Manuel Antunes dos Santos                             
                                                <luis-m-a-santos@telecom.pt>, MPLS-ops Mailing List <mpls-ops@mplsrc.com>              
                      25/03/2004 07:50         cc:                                                                                     
                                               Subject:  RE: [MPLS-OPS]: Question about L2VPN over MPLS                                
                                                                                                                                       





I  think this is very interesting topic. If MPLS wants to emulate ATM
totally, then  support for CBR must be incorporated in the L2 transport
using MPLS permanent  virtual circuits. I haven't seen much support for
COS/diffserv for IP-flows  (VCs) within a single MPLS tunnel (PVC). This is
essential if I want to support  a customer bradcasting Formula1 from
country A to countryB and I have a LSP  tunnel from A>B and this is shared
by other nr-VBR customers. I guess to  deliver the QOS our routers can use
the traditional queing  methods.
Is  there any good implementation/information on this?

Thanks,
Amjad
-----Original Message-----
From: Spice Sylvia  [mailto:falsesylvia@yahoo.co.uk]
Sent: 25 March 2004  02:26
To: McCallum, Robert; Luis Manuel Antunes dos Santos; MPLS-ops  Mailing
List
Subject: RE: [MPLS-OPS]: Question about L2VPN over  MPLS



AFAIK CAR is "rate limiting". It is not a "constant bit rate "

I meant Constant Bit Rate as seen by the 2 ends of the network.

Something like what ATM gives as CBR.

In other words, the network is seen as a "pipe" over which i pump a Bit
pattern at one end at rate X and it appears out at the other end at rate
X.



"McCallum, Robert" <robert.mccallum@thus.net>  wrote:
no  you asked for minimum buffering so that is CAR.



Robert McCallum
CCIE #8757  R&S
01415663448
07818002241
-----Original Message-----
From: Spice Sylvia  [mailto:falsesylvia@yahoo.co.uk]
Sent: 24 March 2004  19:59
To: McCallum, Robert; Luis Manuel Antunes dos Santos;  MPLS-ops Mailing
List
Subject: RE: [MPLS-OPS]: Question about  L2VPN over MPLS


i guess you meant "traffic shapping"?
Actually I meant "commited bit rate".

"McCallum, Robert"  <robert.mccallum@thus.net> wrote:
>Though  another interesting thing I would like to add to your >question is
this:
>Forget the bit rate, let us make it as granualar as we can.  >How do we do
CBR so that we have "minimum buffering" at the >VPLS  /L2VPN edge devices?

Use  CAR??(rate-limiting/policing).


Robert McCallum
CCIE #8757  R&S
01415663448
07818002241
-----Original  Message-----
From: Spice Sylvia [mailto:falsesylvia@yahoo.co.uk]
Sent: 23 March 2004 22:24
To: Luis Manuel Antunes dos Santos;  MPLS-ops Mailing List
Subject: RE: [MPLS-OPS]: Question about L2VPN  over MPLS


Just going a bit off topic here:

The minimum  bit rate is a reflection of the ability of your
multiplexer/demultiplexer to be able to able to give you the "exact"  bits
from the frame where you want to put your  data.

Theoratically, I see no reason why there sh! ! ould be any  limit,

Assume I use a E1 and I channelize it.

As long as  all intermediate devices "know" that from the superframe
structure, bit  1 has to go to A and bit 2 has to go to B and so on, it
really does not  matter.

I believe the current Digital Hierachies talk in terms of  DS0 which is
generally wrapped around to a speed of  64kbps.

Though another interesting thing I would like to add to  your question is
this:
Forget the bit rate, let us make it as  granualar as we can. How do we do
CBR so that we have "minimum  buffering" at the VPLS /L2VPN edge devices?




Yahoo!  Messenger - Communicate instantly..."Ping" your friends today!
Download  Messenger Now

-------
The MPLS-OPS Mailing  List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive:  http://www.mplsrc.com/mpls-ops_archive.shtml


Yahoo!  Messenger - Communicate instantly..."Ping" your friends today!
Download  Messenger Now


Yahoo!  Messenger - Communicate instantly..."Ping" your friends today!
Download  Messenger Now

**********************************************************************
This e-mail message is confidential and is intended only for the use of the
individual or entity named above and contains information which is or may
be
confidential, non-public or legally privileged. Any dissemination or
distribution of this message other than to its intended recipient is
strictly prohibited. You should not copy it or use it for any purpose nor
disclose
the contents to any other person. If you have received this message in
error, please
notify us by email to postmaster@flagtelecom.com immediately and delete the
original message and all copies from all locations in your computer
systems.


This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG
Telecom cannot accept liability for any damage which you may sustain as a
result of software viruses.
**********************************************************************




 This message has been scanned for viruses by MailControl, a service from
                         BlackSpider Technologies.






-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml