From: ccie2be (ccie2be@nyc.rr.com)
Date: Tue Jul 27 2004 - 09:24:05 GMT-3
Yasser,
You've got this all confused.
For example, if you ping an ip address ( and get a response), do you have do
to anything special if the ping travels over a ATM or F/R circuit or
ethernet or token ring or sonet or 802.11b wireless? The answer, of course,
is no.
The ping doesn't care what the layer 2 link technology is. Why is that?
Because at each link's interface, the router takes care of encapsulating the
icmp packet appropriately for the layer 2 technology used on the particular
link needed to send the packet along it's way to the next hop.
Now, suppose that instead of the packet carrying icmp info, it's carrying
voice data. Wouldn't the same thing be true?
The answer is YES. Each router along the path will take the ip packet
carrying voice samples (or call signaling info) and encapsulate it with
whatever layer 2 headers and trailers are appropriate for the type of layer
2 link over which the packet is traveling to it's next hop. And, because of
this, each hop's layer 2 link technology can be different. The first hop
might be ethernet, the 2nd hop could be f/r, the 3rd hop could be ATM, the
4th hop could f/r again, the 5th hop could be wireless, and so on. You get
the idea.
Put simply, when you configue voip, the layer 2 technology is transparent to
the voip traffic.
Now, this transparency comes at a cost. In addition to the whatever headers
and trailer are needed for the layer 2 link, the voice packet must also have
layer 3 headers and trailers and layer 4 headers and trailers as appropriate
for layer 3 (IP) and layer 4 (usually or always UDP). This makes the voice
packet bigger which means more network resource ( rtr cpu and network
bandwidth) is needed to transport the voice packets to their destinations.
Now, suppose your network looks like this:
phone A --> rtr A --> F/R --> rtr B --> phone B
You have a choice: At rtr A and B you can encapsulate the voice traffic in
ip and let the network take care of the layer 2 stuff or you can save
network resources by configuring your rtr's to encapsulate the voice traffic
directly into frame relay. It's your choice (or the choice of those people
creating the lab).
The thing to notice is that there's only one hop. Now, voip and VoFR aren't
mutually exclusive.
Suppose, for example, that rtr 1 is also connected to rtr A by an ATM link
and that phone 1 is attached to rtr1. When phone 1 wants to call phone B,
rtr 1 must use voip (because phone B is 2 hops away). Now, also assume
another phone is attached to rtr B. Let's call that phone B2.
Now, phone A calls phone B and phone 1 calls phone B2. What happens?
At rtr A when the voip traffic arrives from rtr 1, rtr A looks at the dest
ip addr of the voip packet and sees that this packet needs to go to rtr B.
So, just like any ip based traffic, rtr A encapsulates the voip packet
appropriately for the f/r link and sends the packet on it's way. Now, when
a voice packet arrives at rtr A from phone A, rtr A because it's configured
to directly encapsulate voice traffic from phone A into f/r, does that.
So, rtr A because there are 2 calls taking place at the same time is
forwarding both voice traffic streams to rtr B. However, you should realize
at this point that rtr A doesn't even know that the voip traffic from rtr 1
is voip traffic. To rtr A, that traffic is just plain old ip traffic and it
forwards it just as it would any other ip traffic ( except, of course,
probably someone has configured QoS so that voip traffic doesn't have to
wait too long behind FTP traffic or other less time critical traffic).
So, based on this example, you can see that voip doesn't "override" VoFR or
VoATM. They are just different ways of carrying voice traffic.
If you want to really understand this better, I would suggest you read a
couple of books:
1) Integrating Voice and Data Networks, Scott Keagy, ISBN 157870-196-1
A truly excellent book which is well written, clear, full of config examples
and comprehensive.
2) Cisco Voice over Frame Relay, ATM and IP, Steve McQuerry, ISBN
157870-227-5
Not quite as well written as the first book but covers the basics very well
and includes a number of topics that aren't covered in the first book.
3) DQoS, Wendell Odom
Another truly excellent book. If you're planning on becoming a ccie, you
have to know the material in this book inside out. And, since QoS is
critical for voice traffic, you need to understand this broad topic very
well to properly configure a network to handle voice traffic.
All 3 books are available from Cisco Press.
HTH a bit, Tim
----- Original Message -----
From: "Yasser Aly" <yasser.aly@noorgroup.net>
To: "'ccie2be'" <ccie2be@nyc.rr.com>; <trouse@cisco.com>;
<ccielab@groupstudy.com>
Sent: Tuesday, July 27, 2004 2:35 AM
Subject: RE: VOIP over ATM or FR
> Hello,
>
> Based on your reply it might mean that VOIP overrides Vofr and VoATM ?
> I just need to confirm this or otherwise define when Vofr or VoATM would
be
> needed.
>
> Thanks,
> Yasser
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> ccie2be
> Sent: Monday, July 26, 2004 10:34 PM
> To: trouse@cisco.com; ccielab@groupstudy.com
> Subject: Re: VOIP over ATM or FR
>
> If you're configuring VOIP, then you don't need to be concerned about Vofr
> or voATM. The voice traffic flows based on the IP network and doesn't care
> what the layer 2 link technology is.
>
> You still need to configure QoS, but mostly at the L3 level by
prioritizing
> precedence 5 packets or their dscp equivalent. How this is done will
vary
> depending on the layer 2 technology.
>
> HTH a little.
>
>
> ----- Original Message -----
> From: <trouse@cisco.com>
> To: <ccielab@groupstudy.com>
> Sent: Monday, July 26, 2004 11:13 AM
> Subject: VOIP over ATM or FR
>
>
> > He guys,
> >
> > I need some clarification. When configuring VOIP, but traveling over a
> ATM or FR medium, do you still have to address the issues with the L2
> technology. IF so what are the key issues for ATM and FR to keep in mind.
> For example, with ATM do you still have to configure the vbr-rt and COS.
Do
> you have to ahve address the fragmenting of data. If a
question/requirement
> does not speak of this stuff do you still need to configure it. What is
the
> rule of thumb, when the call works and all is pingable but this L2 feature
> and issues are not addressed.
> >
> > Thanks Everyone.
> >
> > _______________________________________________________________________
> > Please help support GroupStudy by purchasing your study materials from:
> > http://shop.groupstudy.com
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Aug 01 2004 - 10:12:04 GMT-3