[c-nsp] Typical E1 provisioning
Mark Rogaski
wendigo at pobox.com
Tue Aug 30 12:00:32 EDT 2005
An entity claiming to be Jessup, Toby (Toby.Jessup at qwest.com) wrote:
: I do not have experience with E1 services.
:
: When E1 data services are ordered from most PTT/providers, such as for
: Internet access, in most places today is the provisioned E1 an
: untructured (unframed) 2048 kb/s data service or is structured 1908 kb/s
: data service actially what most customers get when they ask for "E1" or
: "G.703" (terminology used by vendors and providers can be inconsistent
: or vague).
I'm can't be sure what's the most prevalent, but most of the circuits I've
dealt with are unstructured. If they're calling it G.703, it is probably
unframed. ITU-T G.703 specifies the physical characteristics, G.704 and
G.706 specify the framing and CRC methods.
:
: Is it general best-practice to use the Cisco ts16 command on structured
: E1s used for data links?
If you do get structured service and the PTT doesn't have timeslot 16 reserved
for signalling, it shouldn't cause a problem. And remember that some folks
start counting at 1 instead of 0, so verify that 1-15 and 17-31 are usable.
:
: Many providers offer data services using T1 ports in locations outside
: of North America. In cases where the local PTT/provider does not support
: T1 the PTT/provider may provision a structured E1 and a Cisco router
: with an E1 adapter is configured to use time slots 1-24 (right?). Is
: that all there is to it (on the CPE) when an SP T1-based service is
: provisioned over local PTT E1?
If it's a plain TDM service (ie. not FR or ATM) then the provider is going
to have to provide the details on how they're mapping the T1 payload to
fractional E1.
: Any added performance problems with IMA
: or MLP bundles in these converted scenarios?
:
: Any other interesting gotcha's one ought to know about?
:
Synchronization can be a nightmare with many PTT's. If the E1 is
unstructured, you must provide timing on one side of the circuit and use
recovered timing on the other. If the service is framed, use recovered
timing on both.
With IMA, unless the provider is actually offering indepependent timing
(ITC), you should make sure that all circuits in the IMA Group are
engineered as identically as possible. Despite what the Cisco docs imply,
flapping IMA interfaces are usually due to timing issues ... not
differential delay tolerance. One link with an out-of-phase timing source
can cause significant problems.
And finally, make sure your equipment is taking its timing from a valid
timing reference. If you don't have your own BITS reference, configure
your equipment to use the PTT network (if the PTT is providing timing via a
structured E1). If you have a 2600, 3600, or 3700 make sure you have
network-clock-participate and network-clock-select configured. Relying on
the backplane PLL will result in errors ranging from 1% packet loss to a
complete inability to pass traffic.
Mark
--
[] | Unless sage debate replaces the belligerent strutting
[] Mark Rogaski | now used so extensively, reason will be consumed and
[] wendigo at pobox.com | the death of logic will surely follow.
[] mrogaski at cpan.org | -- Spiro T. Agnew
[] |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://puck.nether.net/pipermail/cisco-nsp/attachments/20050830/087d9424/attachment.bin
More information about the cisco-nsp
mailing list