From: Chris Lewis (chrlewiscsco@gmail.com)
Date: Mon Jun 19 2006 - 10:52:50 ART
IMHO you probably did have the necessary understanding and not all of the
discussion here is relevant to the CCIE R&S.
Simply if a frame travelling from source to destination experiences
congestion within the frame-relay cloud, the FECN bit is set. Once the frame
relay destination switch gets the frame with a FECN in it, it sets the BECN
bit in frames going back to the source. This is simple as we are just
atlking about one DLCI here, it does not relate to all the possible layer 3
hosts at either end of the DLCI. This way the source learns of a congested
path. In this sense, the source is the device closest to the hosts that is
speaking frame relay.
With FRTS enabled on the source frame relay device, BECNs are seen as a
signal to ramp down the transmission rate, possibly all the way down to
mincir. If hosts keep sending at their current rate, shaping queues will
build and lead to a drop, and assuming the source is using TCP (or UDP using
application layer intelligence), this will lead to the host backing off its
transmission rate.
Chris
On 6/19/06, Arun Arumuganainar <aarumuga@hotmail.com> wrote:
>
> mmmm ...Now I am terribly confused !!! I thought I had a fair idea of FRTS
> based on FECN/BECN mechanism !!! I think I overestimated myself .
>
> Can somebody summarize what we have been discussing. For getting maximum
> clarity I would request experts to restrict the discussion in the context
> of
> IP .
>
> Thanks very much in advance.
>
> Thanks and Regards
> Arun
> ----- Original Message -----
> From: "Scott Morris" <swm@emanon.com>
> To: "'Faryar Zabihi (fzabihi)'" <fzabihi@cisco.com>; "'Brian Dennis'"
> <bdennis@internetworkexpert.com>; "'Petr Lapukhov'"
> <petr@internetworkexpert.com>; "'Ken'" <hpnkpn103@yahoo.co.jp>
> Cc: "'Cisco certification'" <ccielab@groupstudy.com>
> Sent: Monday, June 19, 2006 8:33 AM
> Subject: RE: What does FECN do?
>
>
> > Does that cover ALL words in Texas? ;)
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> > Faryar Zabihi (fzabihi)
> > Sent: Sunday, June 18, 2006 12:56 PM
> > To: Scott Morris; Brian Dennis; Petr Lapukhov; Ken
> > Cc: Cisco certification
> > Subject: RE: What does FECN do?
> >
> > Them's fightin words!!!
> > At least it is in TX
> >
> > Faryar
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> > Scott Morris
> > Sent: Sunday, June 18, 2006 9:26 AM
> > To: 'Brian Dennis'; 'Petr Lapukhov'; 'Ken'
> > Cc: 'Cisco certification'
> > Subject: RE: What does FECN do?
> >
> > Wow... I'm sorry, I didn't know these were still current lab topics.
> >
> > I'll jump right up and test that out. And while I'm at it, I think I'll
> > worry about Appletalk and IPX as well in case they come back. What
> about
> > LLC2 or RSRB? I hear token ring is on the rebound.
> >
> > DecNet and CLNS have built in mechanisms for ECN and are much more
> closely
> > related with Layer 2 framing. IP on the other hand has had minor
> mechanisms
> > in the past, but more enhancements lately than for "a very long time".
> > Hence the terminology of passing to "upper layer protocols".
> >
> > So... For the record, if we look at EVERY possibility that you ever may
> run
> > across, then my statement may at times be incorrect. If we have some
> > semblance of paying attention to our lab discussions around here, which
> > revolve in the IP world, then I think you'll find the statement to make
> > perfect sense.
> >
> > And the DocCD writers have had no comment either way on that part.
> > Since you know more than they do, you may want to point that out so then
> at
> > least we can be sure everyone is as politically correct...
> >
> > Scott
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> > Brian Dennis
> > Sent: Sunday, June 18, 2006 2:36 AM
> > To: swm@emanon.com; Petr Lapukhov; Ken
> > Cc: Cisco certification
> > Subject: RE: What does FECN do?
> >
> > Scott,
> > Can you post an example configuration of how to configure DECnet support
> for
> > FECN since you say it's not the default? The reason I ask is because
> the
> > DocCD states that "no configuration is required" which normally means
> > "default".
> >
> > <DocCD>
> > Cisco's Implementation of Frame Relay
> >
> > The Frame Relay software provides the following capabilities:
> >
> > * Transmission of congestion information from Frame Relay to DECnet
> Phase
> IV
> > and CLNS. This mechanism promotes Forward Explicit Congestion
> Notification
> > (FECN) bits from the Frame Relay layer to upper-layer protocols after
> > checking for the FECN bit on the incoming DLCI. Use this Frame Relay
> > congestion information to adjust the sending rates of end hosts.
> > FECN-bit promotion is enabled by default on any interface using Frame
> Relay
> > encapsulation. No configuration is required.
> > </DocCD>
> >
> > Also if this is against Cisco's long-standing idea as you say someone
> better
> > let the people who write the DocCD know ;-)
> >
> > Thanks!
> >
> > Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
> > bdennis@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-224-8987
> > Direct: 775-745-6404 (Outside the US and Canada)
> >
> > ________________________________
> >
> > From: Scott Morris [mailto:swm@emanon.com]
> > Sent: Sat 6/17/2006 1:22 PM
> > To: Brian Dennis; Petr Lapukhov; 'Ken'
> > Cc: 'Cisco certification'
> > Subject: RE: What does FECN do?
> >
> >
> > However, unless specifically configured on Cisco devices, received
> BECN's
> or
> > FECNs have been routinely ignored regardless of the upper layer protocol
> > support. Cisco is not alone in this long-standing idea though.
> >
> > Just because you CAN do it, doesn't mean you will. ;)
> >
> > scott
> >
> > ________________________________
> >
> > From: Brian Dennis [mailto:bdennis@internetworkexpert.com]
> > Sent: Saturday, June 17, 2006 12:37 PM
> > To: Scott Morris; Petr Lapukhov; Ken
> > Cc: Cisco certification
> > Subject: RE: What does FECN do?
> >
> >
> > It really depends on the upper layer protocols in regards to Cisco's
> support
> > and there has been support for FECN and BECN for protocols that
> understood
> > the concept of an ECN (Explicit Congestion Notification).
> > The IOS has supported DECnet and OSI for a very long time. Also SNA
> using
> > direct encapsulation LLC2 encapsulation supports BECN.
> >
> > Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
> > bdennis@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-224-8987
> > Direct: 775-745-6404 (Outside the US and Canada)
> >
> >
> >
> >
> > ________________________________
> >
> > From: nobody@groupstudy.com on behalf of Scott Morris
> > Sent: Sat 6/17/2006 9:27 AM
> > To: Petr Lapukhov; 'Ken'
> > Cc: 'Cisco certification'
> > Subject: RE: What does FECN do?
> >
> >
> >
> > While very true, this gives an example of us being concerned with our
> > endpoints only. (Which very well may be the design of the network these
> > days!)
> >
> > The history of FECN and BECN was revolving around a true end-to-end
> > frame-relay network, and a Frame Switch in the middle would actually
> > generate both types of ECNs (each a separate bit within the frame relay
> > frame format).
> >
> > The FECN would follow with the traffic telling receiving stations (upper
> > layer protocols, if informed) to expect some delays in incoming traffic
> due
> > to congestion. The BECN would go on the back path telling the receiver
> to
> > slow down in transmission. If, of course, it were paying attention to
> > those! Cisco's default behavior is to ignore these notifications. Go
> > figure.
> >
> > In today's frame-relay networks though, where SPs often re-encapsulate
> the
> > frames into IP-IP tunnels, or MPLS clouds or whatever their choice is,
> the
> > functionality is a bit warped.
> >
> > http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/frame.htm#wp102
> > 0620
> >
> > There are capabilities for ECN marking within MPLS clouds (MPLS-VPN),
> but
> I
> > don't have any data suggesting which service providers do or do not
> actually
> > support this.... Bottom line, in real life you should know your
> network's
> > capabilities. In the lab, you should do whatever the lab asks for!
> >
> > Ahhhhh..... Evolution. ;)
> >
> >
> > Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713,
> JNCIE
> > #153, CISSP, et al.
> > CCSI/JNCI
> > IPExpert CCIE Program Manager
> > IPExpert Sr. Technical Instructor
> > smorris@ipexpert.com
> > http://www.ipexpert.com
> >
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Petr
> > Lapukhov
> > Sent: Saturday, June 17, 2006 8:27 AM
> > To: Ken
> > Cc: Cisco certification
> > Subject: Re: What does FECN do?
> >
> > Ken,
> >
> > Most of the time FECN is an informative bit, that may be used simply for
> > statistical purposes.
> >
> > On the over hand, BECN frames actually signal source to slow down, but
> that
> > would work okay only if data exchange is bidirectional.
> >
> > Now, for a good example of FECN usefulness consider "frame-relay
> > fecn-adapt" command wihin map-class.
> > (Or it's equivalent "shape fecn-adapt" with MQC).
> >
> > Imagine that you have unidirectional stream of packets (e.g. video feed)
> > that overloads your FR network. You will have a lot of FECN bit set
> packets
> > in direction from sender to receivers, but not a single packet
> backwards,
> so
> > no BECN frames will arrive to sender.
> >
> > Here you may use fecn-adapt, that enables reflection of FECN bit in
> special
> > FR frames back to sender with BECN bit set. In this way, a FECN
> signalling
> > is converted to BECNs, that actually signal sender to slow down sending
> > rate.
> >
> > http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/
> > fqos
> > _r/qrfcmd9.htm#wp1103558
> >
> > HTH
> >
> > --
> > Petr Lapukhov, CCIE #16379
> > petr@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-224-8987
> > Outside US: 775-826-4344
> > 24/7 Support: http://forum.internetworkexpert.com
> > Live Chat: http://www.internetworkexpert.com/chat/
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Jul 01 2006 - 07:57:33 ART