[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Switching technologies requiring bidirectional asymmetric LSPs?
Thanks Martin,
Most applications generate asymmetric (wrt time) information flows in each direction, ie the rate of information flow in each direction is neither constant nor directly proportional to the rate of information flow in the other direction....just think about a voice conversation if not obvious....or even a file transfer.
However, for an arbitrarily meshed network we generally require symmetric routings of traffic flows, ie if one direction passes the nodes a->b->c->d in one direction then the other direction should follow d->c->b->a in both this and lower layer networks (to the duct). Moreover, we usually require (under failure free conditions) that such routings do not change over the lifetime of a traffic flow.......this is particularly important for connections (ie co-ps and co-cs modes), and especially when they are supporting a network builder service (a VPN if you like), which may be a large aggregate of all kinds of end-system application traffic flows, for some other party. Note that if we add nodes/links to a co mode layer network we should not change existing connection routings. This is not always the case with a cl-ps mode network, ie because we do not have connections adding new nodes/links can allow traffic flows to change routing.
Is that more clear now wrt what I meant?
regards, Neil
> -----Original Message-----
> From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.fr]
> Sent: 19 April 2007 09:37
> To: Harrison,N,Neil,JCGA1 R; Attila.Takacs@ericsson.com;
> i_bryskin@yahoo.com; adrian@olddog.co.uk; lberger@labn.net
> Cc: ccamp@ops.ietf.org
> Subject: Re: Switching technologies requiring bidirectional
> asymmetric LSPs?
>
>
> Neil,
>
> for clarification purposes, the asymmetry I was referring to
> was in terms of bandwidth not path/route or other TE
> parameter, but maybe I did not catch what you meant by *routings*.
>
> regards,
>
> martin
>
> neil.2.harrison@bt.com a écrit :
> > I would caution against the observation that because traffic flows
> > a->b and b->a are invariably asymmetric (wrt resource
> consumed at any
> > epoch) their *routings* can also be asymmetric....this does
> not follow
> > at all. This observation applies to all layer networks (any
> > mode/technology).
> >
> > regards, Neil
> >
> >> -----Original Message-----
> >> From: owner-ccamp@ops.ietf.org
> >> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Martin Vigoureux
> >> Sent: 19 April 2007 08:34
> >> To: Attila Takacs (IJ/ETH); Igor Bryskin; Adrian Farrel; Lou Berger
> >> Cc: ccamp@ops.ietf.org
> >> Subject: Re: Switching technologies requiring bidirectional
> >> asymmetric LSPs?
> >>
> >>
> >> All,
> >>
> >> I do believe in the need for asymmetric bidirectional LSPs.
> >> Traffic is by nature asymmetric (for the vast majority of it
> >> at least). We may argue that the sum of asymmetric traffic
> >> could lead to symmetric traffic or that the above statement
> >> is dependent on the network segment we are considering, but
> >> it will remain true and we should definitely capitalize on
> >> CCAMP prior work by taking benefit from the advantages of
> >> bidirectional LSP setup.
> >>
> >> Furthermore, I believe we should not restrict the work and
> >> solution to Ethernet technology only.
> >>
> >> martin
> >>
> >> Attila Takacs (IJ/ETH) a écrit :
> >>> Hi all,
> >>> please see inline [at]
> >>> Regards,
> >>> Attila
> >>>
> >>>
> >> --------------------------------------------------------------
> >> ----------
> >>> *From:* owner-ccamp@ops.ietf.org
> >> [mailto:owner-ccamp@ops.ietf.org]
> >>> *On Behalf Of *Igor Bryskin
> >>> *Sent:* Tuesday, April 17, 2007 10:19 PM
> >>> *To:* Adrian Farrel; ccamp@ops.ietf.org; Lou Berger
> >>> *Subject:* Re: Switching technologies requiring bidirectional
> >>> asymmetric LSPs?
> >>>
> >>> Adrian, Lou
> >>>
> >>> Please,see in line.
> >>>
> >>> */Adrian Farrel <adrian@olddog.co.uk>/* wrote:
> >>>
> >>> Hi,
> >>>
> >>> I'm a bit surprised that there was no follow-up to Lou's
> >>> email.
> >>>
> >>> Does silence indicate that this was put to bed in
> Prague and
> >>> no-one is
> >>> interested in these LSPs?
> >>>
> >>> [at] well, as Lou mentioned at least a few of us
> continue an
> >>> offline discussion on the topic.
> >>>
> >>> > So a few of us have been having been discussing the
> >>> asymmetric work
> >>> > presented in Prague and it seems to me we have an open
> >>> question on
> >>> > requirements.
> >>> >
> >>> > It's clear that at least one switching
> technology (i.e.,
> >>> ethernet/PBB-TE)
> >>> > requires support for bidirectional asymmetric LSPs.
> >>>
> >>> Is this clear? I continue to hear talk of service
> >> requirements,
> >>> but not so
> >>> much of how those services are required to be supported.
> >>>
> >>> The benefits I have heard are:
> >>> 1. Fewer control plane messages
> >>> 2. Ease of enforecement of fate-sharing
> >>>
> >>> IB>> Adrian, you enumerated here the benefits of
> >> bidirectional
> >>> LSPs, and BTW you forgot to mention the most
> important one.
> >>> Ethernet OAM is designed, as I understand, on
> >> assumption that
> >>> the trafic takes the same paths in both
> >> directions. So, if we
> >>> want to preserve the Ethernet native OAM (which we
> >> certainly do
> >>> , because this is half of Ethernet functionality)
> >> we must map a
> >>> bidiretcional service on either a single
> >> bidirectional LSP or
> >>> two unidirectional LSPs using the same path. This
> >> is different
> >>> form MPLS where there are no such OAM requirements.
> >>> Lou is talking about asymetrical bi-directional
> >> LSPs, and what
> >>> is not clear (at least for me) whether we need
> >> asymetrical p2p
> >>> Ethernet services.
> >>>
> >>> [at] Adrian's points are related to the single session vs.
> >>> multiple session discussions we had, which is
> >> generally true for
> >>> any bidirectional LSP.
> >>> The bidirectionality of Ethernet comes basically from two
> >>> aspects imho: (1) in any case, as Igor pointed out,
> >> most of the
> >>> CFM functions will only operate properly if there are
> >>> symmetrical paths. (2) on the other hand, if a
> GMPLS LPS is
> >>> essentially a VLAN within which MAC learning is
> >> operating one
> >>> will need symmetric paths in order the learning functions
> >>> properly.
> >>>
> >>> I had the impression that we already converged
> >> before Prague to
> >>> a single remaining question: do we need the
> >>>> asymmetric bw<<
> >>> extension for a single session bidirectional LSP.
> There were
> >>> some possible cases for asymmetric bw LSPs
> mentioned by Don,
> >>> Diego and myself but these seemed not to convince
> >>> everybody. Imho we should focus on this question
> not to loop
> >>> into the discussion we had already.
> >>>
> >>> If we agree on that bidirectional services over
> >> Ethernet need
> >>> symmetrical paths than we could conclude that
> using a single
> >>> session to setup the bidirectional LSP would be the
> >> preferred
> >>> way at least over Ethernet. In this case, imho it is quite
> >>> reasonable to assume that asymmetrical services
> >> that require a
> >>> dedicated LSP would also use a single signaling
> exchange to
> >>> setup the LSP, hence there would be a need for the
> >> asymmetric bw
> >>> extension. Following this thinking, the question
> >> turns into the
> >>> aggregation/hierarchy discussion that was bought up
> >> by Dimitri
> >>> earlier. That is, do we have the need of LSPs per
> >> service. My
> >>> two cents: generally not but there are certain
> >> services where it
> >>> is indeed a reasonable assumption, e.g., IPTV or private
> >>> services.
> >>>
> >>> These are significant, but not dramatic, requirements.
> >>>
> >>> > The question is:
> >>> >
> >>> > Is the *requirement* for bidirectional asymmetric LSPs:
> >>> > (a) a technology specific requirement, or
> >>> > (b) one that is common (this is CCAMP after
> >> all!) to multiple
> >>> switching
> >>> > technologies?
> >>>
> >>> CCAMP deals in transport networks. As far as I can
> >> see the service
> >>> requirements would be pretty much the same all transport
> >>> networks and would
> >>> certainly be applicable to packet, L2, and TDM (the latter
> >>> because TDM will
> >>> be called on to support L2).
> >>>
> >>> IB>> See my comment above: there is a differnce
> >> between MPLS and
> >>> Ethernet services. Also there are certainly
> >> differences between
> >>> MPLS and lambda services (use of the same lambda in both
> >>> directions, for example). So each transport
> >> technology may have
> >>> distinct requirements WRT bidirectional services
> >> and connections
> >>> on which the services are mapped.
> >>>
> >>> > Please keep in mind that service requirements
> are not the
> >>> same thing as
> >>> > switching technology requirements. For example,
> >> we have long
> >>> built
> >>> > bidirectional asymmetric services on
> unidirectional MPLS
> >>> LSPs.
> >>>
> >>> Well, exactly!
> >>> Perhaps someone can explain why the Ethernet
> >> hardware is forced
> >>> to require
> >>> bidirectional asymmetric LSPs when MPLS is happy without?
> >>>
> >>> IB>> Again, IMO the answer is to be able to use native
> >>> Ethernet OAM.
> >>>
> >>> Igor
> >>>
> >>> > The answer to this question will help determine
> >> if we should
> >>> have a
> >>> > technology specific solution or a generic CCAMP
> >> solution (as
> >>> well as the
> >>> > complexity of the solution.)
> >>>
> >>> We should not take any action that deliberately
> precludes or
> >>> makes more
> >>> complex the genericisation (is that an American
> >> word?) of the
> >>> solution
> >>> unless there is a significant difference in simplicity of
> >>> solutions.
> >>>
> >>> But we should take no action at all unless there is
> >> some more
> >>> evidence of
> >>> support for this work!
> >>>
> >>> Adrian
> >>>
> >>>
> >>>
> >>>
> >>>
> >> --------------------------------------------------------------
> >> ----------
> >>> Ahhh...imagining that irresistible "new car" smell?
> >>> Check out new cars at Yahoo! Autos.
> >>>
> >>>
> >> <http://us.rd.yahoo.com/evt=48245/>
> >> *http://autos.yahoo.com/new_cars.htm
> >>
> l;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWN
> >>> hcnM->
> >>>
> >>
> >
>